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About This Guide 


Purpose 


This guide instructs the Unisys System 80 programmer in the use of Unisys Operating 
system/3 (OS/3) consolidated data management. 


Scope 
This guide 


e Explains what consolidated data management is, how it works, describes the data 
structures that are involved, and explains how errors and exceptions are 
handled. 


e Describes the formats and conventions for the various types of files and discusses 
those things you must consider when using each type of file in your program. 


Audience 


The primary audience for this guide is the programmer who requires information on 
the various types of files that can be used in a program. 


Prerequisites 


Anyone using this guide should be familiar with OS/3. 


How to Use This Guide 


Read the entire guide to familiarize yourself with consolidated data management; 
then use it, as needed, to provide information on the types of files you intend to use in 
your program. 
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Organization 


vi 


This guide contains seven sections and five appendixes. 

Section 1. Introduction 

This section describes what consolidated data management is, how it works, describes 
the data structures that are involved, and explains how errors and exceptions are 
handled. 


Section 2. Card Formats and File Conventions 


This section describes how card files are organized, shows the card record formats, and 
discusses those things you must consider when using card files in your program. 


Section 3. Printer Formats and File Conventions 

This section describes how printerfilesare organized, shows the printer record formats, 
and discusses those things you must consider when using printer files in your 
program. 

Section 4. Magnetic Tape Formats and File Conventions 

This section dcscribes how magnetic tape files and volumes are organized, shows the 
tape record formats, and discusses those things you must consider when using 
magnetic tape files in your program. 

Section 5. Disk and Format Label Diskette Formats and File Conventions 
This section describes how these files are organized, shows the record formats, 
provides formulas for estimating space requirements for a data file, and discusses 
those things you must consider when using these files in your program. 


Section 6. Data Set Label Diskette Formats and File Conventions 


This section describes how diskette files are organized, shows the record formats, and 
discusses those thing you must consider when using diskette files in your program. 


Section 7. Workstation Formats and File Conventions 

This section describes how workstation files are organized, shows the record formats, 
and discusses those things you must consider when using workstation files in your 
program. 


Appendix A, Functional Characteristics of Input/Output Devices 


This appendix provides summaries of the functional characteristics of the various I/O 
devices. 
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Appendix B. Code Correspondences 


This appendix provides the hexadecimal value, the binary value, and the Hollerith 
punched card code for all ASCII and EBCDIC characters. 


Appendix C, DD Job Control Statement Processing 


This appendix describes how the the DD job control statement can n be used to 
temporarily change file parameters at run time. 


Appendix D. Shared Code and Accelerated File Access 


This appendix describes how you use shared code to improve the performance of 
consolidated data management when accessing files. 


Appendix E. Data Management Debugging Facility 


This appendix describes how you can use the data management debugging facility to 
provide you with a system dump when an unexpected data management error occurs. 


Related Product Information 


@ The following Unisys documents may be useful in understanding and using 
consolidated data management: 


Note: Throughout this guide, when we refer you to another manual, use the current 
version that applies to the software level in use at your site. 


Interactive Services Operating Guide (UP-9972) 


This guide describes the procedures used to communicate interactively through a local 
workstation or remote terminal with the operating system. 


System/32, 34 to OS/3 Conversion Guide (UP-9318) 

This guide describes the guidelines for converting from IBM System/32, 34 to OS/3. 
Installation Guide (UP-8839) 

This guide describes how to generate, install, and tailor your operating system. 
Supervisor Technical Overview (UP-8831) 


This overview describes the concepts of the component that provides the central 
control necessary for the optimum utilization of system hardware and software. 
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System Service Programs (SSP) Operating Guide (UP-8841) 

This guide describes the system service programs. 

Data Utilities Operating Guide (UP-8834) 

This guide describes how to reproduce and maintain data files. 

Job Control Language Programming Guide (UP-9986) 

This guide provides information on the format and use of job control statements. 
System Messages Reference Manual (UP-8076) 


This handbook lists and describes the messages that are displayed on the system 
console during program execution. 


COBOL, 1974 American National Standard Programming Reference Manual 
(UP-8613) 


This manual describes how to use the 1974 ANSI COBOL programming language. 
FORTRAN IV™ Programming Reference Manual (UP-8814) 


This manual describes how to use the FORTRAN IV programming language. 





Report Program Generator II (RPG II) Programming Guide (UP-8067) 
This guide describes how to use the RPG II programming language. 
Operations Guide (UP-8859) 


This guide describes the procedures and commands used to operate System 80. 


FORTRAN IV is a trademark of SuperSoft Associations. 
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Introduction 


1.1. General Information 


As you know, all computer programs process data in one form or another; however, the 
data and the program are in two different places. The program is executed in the main 
storage section of the central processing unit (CPU) and the data is contained on 
devices external to the CPU. In order to process the data and produce the desired 
results, data must be moved in from and out to these peripheral devices. Because the 
physical and electronic characteristics of the various devices differ, it can lead to 
problems if you have to take the characteristics of a device into consideration each 
time you want to perform an input/output (I/O) operation. Obviously, there is a need 
for some way to specify an I/O operation in a program on a logical level. The answer to 
this need is consolidated data management. 


1.2. What Is Consolidated Data Management? 


Consolidated data management is a collection of program modules that are written for 
each of the I/O devices supported by your system. These modules handle the actual 
movement of data. They take care of all the device characteristic requirements; 
consequently, you need not worry about this when you want to perform I/O operations. 
All you need to do is make a formal request in your program to data management and 
it moves the data in from or out to the particular I/O device. Figure 1-1 illustrates the 
relationship between data management and your program. 
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Figure 1-1. Relationship of Consolidated Data Management to a Program 


As you can see in Figure 1-1, data management acts as the data transfer mechanism 
between your program and the I/O devices. 
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1.3. How Consolidated Data Management Works 


When you write your program, you establish a unique file name for each I/O device 
you intend to use. You then describe the characteristics for each file. Once this is done, 
you use these file names in conjunction with I/O commands at each point that you 
want to move data into or out of your program. The I/O commands act as formal 
requests to data management. After your program is written, it must be processed by 
the applicable language processor (assembler, FORTRAN, COBOL, or RPG ID to form 
an object module. The next step is to link edit your program to produce a load module 
(an executable program). 


When the time comes to execute your program, you use job control language 
statements to associate each file name in your program with the particular device you 
want to get data from or send data to. Once this is done, you can proceed to execute 
your program. The appropriate data management modules are placed in main storage 
at this time as shown in Figure 1-2. 


Thereafter, each time an input or output command is encountered during processing, 
the applicable data management module gets data from or sends data to the 
appropriate device. 


SOURCE LANGUAGE 
STATEMENTS FOR 
YOUR PROGRAM 

















LANGUAGE OBJECT LINKAGE LOAD 
PROCESSOR MODULE EDITOR MODULE 
CONTAINING CONTAINING 
YOUR YOUR 
PROGRAM PROGRAM 


CONSOLIDATED 







PROGRAM COPY REQUIRED 





MODULES DATA 
EXECUTION (See Note) MANAGEMENT 
LOAD 
MODULES 


Note: Based on device assignment sets for files in the job control stream, the required modules are copied at 
execution time. 


Figure 1-2. Consolidated Data Management Program Development Cycle 


UP-9978 Rev. 1 1-3 


Introduction 


1.4. Data Structure 


Consolidated data management recognizes the following as structural entities: 


Volume 
The largest physical unit for data storage; such as tape reel or disk pack. 
File ; 


A delimited storage space having an identifying file name and consisting of a 
collection of related data. 


Block 


That portion of a file that is transferred into or out of main storage by a single 
access. | 


Record 


A collection of contiguous characters that you have designated to be handled as a 
unit. 


Field 


One or more contiguous characters within a record that represents a single piece 
of information. 


The volume concept is not truly applicable to printers, workstation, or card devices. 
On disk, diskettes, and magnetic tape, a file may be larger than a volume; that is, a 
file may require more than one physical unit to hold it. In this case, you have what is 
called a multivolume file. Figure 1-3 shows the organization of data on the peripheral 
devices supported by consolidated data management. 


1-4 
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a. Disk pack 


Note: The set of tracks at a specific radius on all recording surfaces is called a cylinder. 


Figure 1-3. Organization of Data on Peripheral Devices (Part 1 of 3) 
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c. Printer 
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d. Punched card 


Figure 1-3. Organization of Data on Peripheral Devices (Part 2 of 3) 
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f. Workstation 


Figure 1-3. Organization of Data on Peripheral Devices (Part 3 of 3) 
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1.5. Error and Exception Handling 


During program execution, consolidated data management monitors each 
input/output request and notifies you when an error or exception occurs so that you 
can take appropriate action. This notification consists of messages that are logged on 
the printer or displayed at the console. 


1.5.1. Error Messages 
The error messages issued by data management have the following format: 
DM nn chan/device explanatory- text, TYPE=nn 
As you can see, these messages consist of the prefix DM followed by a number, the 
channel and device address, and text explaining what caused the error. Some 
messages have the suffix TYPE=nn, where nn is a subcode that further defines the 


error. A complete list of the data management messages along with suggested actions 
is provided in the System Messages Reference Manual (UP-8076). 


1.5.2. Return of Control 


Consolidated data management is designed so that control is always returned to your 
program when an error is detected; that is, your program is never terminated. When 
an error occurs, the applicable error message is logged or displayed and control is 
returned to your program inline at the next sequential instruction after the 
instruction that caused the error. 


1.6. Related Software 


There are several software components that are indirectly involved with data 
management or perform functions required for program operation. These components 
include: 

e System service programs (SSP) 

e Job control 


e Supervisor 


e Data utilities 


1.6.1. System Service Programs {SSP} 


The SSP are those routines that you use to prepare disk, diskette, and magnetic tapes 
to accept data records, to create program load modules, to obtain printouts (dumps) of 
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main storage, and to construct and reorganize your program libraries. These routines 
are described in detail in the System Service Programs (SSP) Operating Guide 
(UP-8841). 7 

The disk prep routine performs a surface analysis of the disk or diskette tracks and 
assigns alternate tracks if defects are discovered. It also establishes a volume table of 
contents (VT'OC) for the device so that files may be placed on it. 


The magnetic tape prep routine prepares a magnetic tape by writing the initial 
volume label, dummy file header label, dummy file trailer label, and tape marks. 


The linkage editor is used to create your program load module. 


The dump routines allow you to obtain narrative or nonnarrative printouts of main 
storage. 


The system librarian allows you to construct and reorganize your program libraries. 


1.6.2. Job Control 


A major function of job control is the assignment of the required peripheral devices. 
These are assigned through job control statements that specify logical unit numbers, 
alternate device types, and information about the file. These statements include: 

¢ DVC statement - assigns device number. 


¢ VOL statement - identifies tape, disk, and diskette volumes. 


¢ EXT statement - provides disk extent information (amount of disk or diskette 
space required for your file). 


e LBL statement - identifies the physical file on tape, diskette, or disk. 


e LFD statement - associates the file defined in your program with the physical file 
on the device. 


Other functions provided by job control include loading the vertical format buffer 


(VFB) and the load code buffer (LCB). For details on job control, see the Job Control 
Language Programming Guide (UP-9986). 
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1.6.3. Supervisor 
The supervisor provides the largest amount of support for your program and data 
management. For the most part this support is automatic and therefore is not 
apparent during the execution of your program. This support includes 


¢ Physical input/output control system (PIOCS) 


Handles the actual transfer of physical records between the I/O devices and main 
storage. 


¢ Transient scheduling routines 


Retrieve transient routines, such as the file open and close routines, and bring 
them into main storage for execution. 


¢ Operator communications routines 
Handle the communications concerning volume mounting requests, and so on. 
e File protection routines 
Protect files and records during shared file processing. 
e Timer services routine 
Compute run time, scheduling, and so on. 
e Disk space management routines 


Allocate disk space and maintain space accounting through procedures that 
update the volume table of contents (VTOC) on disk files. 


1.6.4. Data Utilities 


A data utility routine is provided to assist you in manipulating data files and 
preparing card decks. This routine edits or corrects data records, or copies them from 
one device to another. 


See the Data Utilities Operating Guide (UP-8834) for details concerning this routine. 
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Section 2 
Card Formats and File Conventions 


2.1. General Information 


A punched card file consists of a card deck that is input via a card reader or output via 
a card punch. Records can comprise either a portion of a card or a complete card. The 
basic punched cards for the card subsystems are the standard 80-column cards. 
However, optional hardware features allow you to read 51- or 66-column cards. 


Refer to Appendix A for the functional characteristics of the card subsystems that are 
supported. 


2.2. File Organization 


Punched card files are sequential files; that is, the records are handled one at a time 
in sequential order. The card deck consists of a start-of-data job control card 
(optional), data cards containing one record each, and a end-of-data job control card. 


Figure 2-1 shows a typical card file structure. 








END-OF-DATA 
JOB CONTROL => 
CARD 


1 TO n CARDS FOR INPUT FILES 
EACH CONTAINING THESE CARDS MAY HAVE 
A SEPARATE RECORD 51, 66, 80, OR 96 


COLUMNS 


FOR OUTPUT FILES 
THESE MUST 


START-OF-DATA BE 80-COLUMN CARDS 


JOB CONTROL 
CARD 
(OPTIONAL) 


Figure 2-1. Typical Card File Structure 
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2.2.1. Card Input Files 


A card input file consists of fixed-length, unblocked records; that is, all records are the 
same size. When a record is read, it is placed in the I/O area. Figure 2-2 shows the 
record format for fixed-length, unblocked records. 


data 


a ee 
Legend 


A ___ Data record length. The |/O area must be at least the same size as the record length and must be an even 
number of bytes. If you are using 51-column cards, the |/O area must be specified as 52 bytes. 


Figure 2-2. Fixed-Length, Unblocked Record Format for Card Input Files 


2.2.2. Card Output Files 


A card output file consists of data that is formed into records, either in the I/O area or 
a designated work area, and then is sent to the card punch, where the records are 
punched in the standard 80-column card format. The output records can be fixed 
length or variable length. These record formats are shown in Figure 2-3. 
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FIXED LENGTH 


VARIABLE LENGTH 


aa ~ 








|< D > |< ______________—-—__ A | 
I< C >| 
< F >| 

Legend 

b Block size field, 4 bytes 

r Record length field, 2 bytes 

u Reserved (2 bytes); may be any 2 characters chosen by the user 

A Data record length 

C Variable record length 

D Record size field 

F /0 area layout. The !/O area must be an even number of bytes and its size must equal the maximum record 


size plus the block size and record size fields if you are dealing with variablelength records. 


Figure 2-3, Record Formats for Card Output Files 


2.3. Card File Programming Considerations 


The following points must be considered when you use card files with your program: 


ds 


~ 
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The file name that you use in your program for a card file must be associated 
with a card I/O device via a DVC-LFD job control statement series in the job 


control stream at program execution. See the job control user guide for details on 
these statements. 


If you intend to process 51- or 66-column cards, the device number that you 


specify in the DVC job control statement for that file must be the number of a 
device that supports the required feature. 
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3. Ifyour files require either input or output translation (the conversion of an 
existing character to another), you must provide a translation table in your 
program. See the applicable programming language guide for details. 


4, Ifyou intend to read or write ASCII files, you must indicate this when you 
describe the file in your program. This is necessary because the internal code in 
the system is EBCDIC and data management must be alerted so that it can 
translate the incoming data to EBCDIC (via the data management ASCII-to- 
EBCDIC translation table) or the outgoing data to ASCII (via data management 
EBCDIC-to-ASCII translation table). See the applicable programming language 
guide for details. | 
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Section 3 
Printer Formats and File Conventions 


3.1. General Information 


A printer file consists of data that you create in your program and cause to be printed, 
one line at a time, on a printer device. Each printed line can have up to 160 
characters, depending upon the printer subsystem you use. 


Refer to Appendix A for the functional characteristics of the printer subsystems that 
are supported. 


3.2. File Organization 


Printer files can be organized to produce text, tabular data, or data on preprinted 
forms. In each case, you must set up the data you want printed on each line, must 
control the vertical separation between lines, and must provide for skipping to the 
next page when the space on the current page is exhausted. (See the applicable 
programming language guide for details.) 


3.2.1. Text 


The simplest printer file is one that consists entirely of text. An example of this is the 
lines you are presently reading. If you had to write a program to produce these lines, 
each line would be a record and you would form each line in an I/O area or work area. 
Then you would cause it to be printed. This process is repeated for each line until the 
end of the page is reached, at which point you issue an instruction to skip to the top of 
the next page. 


3.2.2. Tabular Data 


The records for tabular data and reports are formed in the same manner as in text 
files (in an I/O area or work area). In these cases, your program is more complex 
because of vertical and horizontal spacing requirements, page and column headings, 
and other repetitive items (see Figure 3-1). 
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PAGE HEADING 
a 


7 __—_DAILY ACTIVITY REPORT 
COLUMN TRANS- QUAN 
HEADINGS 






DEPARTMENT 


DESCRIPTLON ACTION ON-HAND 
OOOIOE CAPACITOR OKDER 
00010F ROTOR ORDER 
00010G POINTs IGN ORDER 







BILLED 
PRODUCTION 
PRODUCTION 
MAINTENANCE 





Figure 3-1. Sample Tabular Data 


3.2.3. Data on Preprinted Forms 
A printer file that places data on a preprinted form is easy to use once it is organized. 
You form your records in an I/O area or work area as with text or tabular data. The 


difference, as you can see in Figure 3-2, is that you have to closely control the 
positioning of your data. 


UNISYS 
P. O. BOX 500 
BLUE BELL, PA. 19422 


SITE 3-1 


ATTN: CATHY SMITH 


D6866M 6595 Up 6O71 


ADORESS CORRECTION REQGUESTEO 
RETURN POSTAGE GUARANTEED 


U01-527 





Figure 3-2. Sample of Data on Preprinted Form 
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3.3. Printer Record Formats 


The printer record formats are shown in Figure 3-3. As you can see, a record may 
contain a control character that specifies line spacing or skipping when the file is 
printed. This character is not printed, but is a part of the record in storage. 


FIXED LENGTH 


data, fixed length 





UNDEF INED 


data, variable length 





®& VARIABLE LENGTH 


data,- variable length 





D 








Se 


Legend 


b Block size field, 4 bytes 

cc Control character, 1 byte, optional 

Record length field, 2 bytes, binary 

Reserved (2 bytes); can be any 2 characters you choose 
Data record length 

Variable record length 

Record size field 

/O area layout 


TOO, 4c 


Figure 3-3. Printer Record Formats 
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3.4. Vertical Format and Load Code Buffers 


All printers contain a vertical format buffer and a load code buffer. The vertical format 
buffer is used to define the printer page in terms of the number of lines per page, the 
density of the lines, the overflow line, and the codes you can use with your program 
instructions to skip to specific lines on a page. 


The load code buffer specifies the 8-bit codes that are associated with the graphic 
symbols on the print cartridge, band, or drum. 


Normally, the vertical format buffer and the load code buffer are set up at system 
generation time for each printer type. For details, refer to the Installation Guide 
(UP-8839). 


Normally, your only concern with these buffers is to know what standards are 
established for the printer you are going to use with your program. In most cases, 
these standards allow you to produce the printed output you require. 


3.5. Printer File Job Control Considerations 


The following points must be considered when you use printer files with your 
program: 


1. The file name that you use in your program for a printer file must be associated 
with a printer device via a DVC-LFD job control statement series in the job 
control stream at program execution. See the Job Control Language 
Programming Guide (UP-9986) for details on these statements. 


2. Ifyou intend to process records that are larger than 120 characters, the device 
number that you specify in the DVC job control statement for that file must be 
the number of a device that has the required feature. 


3. You must include a VFB job control statement in the DVC-LFD statement series 
for your printer file if: 


e You want to use one of the filed vertical format buffers (established at 
SYSGEN time or by use of the job SG$PRB) rather than the default vertical 
format buffer used when no VFB statement is specified. 


¢ Your forms control requirements cannot be met by the vertical format buffer 
that was established at SYSGEN time. In this case, the VFB statement is 
used to specify a unique vertical format that meets your needs. When the 
program is executed, the vertical format buffer you specified via the VFB 
statement is used instead of the one specified at SYSGEN time. See the Job 
Control Language Programming Guide (UP-9986) for details on the VFB 
statement. 
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You must include an LCB job control statement in the DVC-LFD statement series 
for your printer file if 


¢ You want to use one of the filed load code buffers (established at SYSGEN 
time or by use of the job SG$PRB) rather than the default load code buffer 
used when no LCB statement is specified. 


e Your requirements cannot be met by the load code buffer that was 
established at SYSGEN time. The LCB statement is used to specify a unique 
load code buffer that meets your needs. When the program is executed, the 
load code buffer you specified via the LCB statement is used instead of the 
one specified at SYSGEN time. 


See the Job Control Language Programming Guide (UP-9986) for details on the 
LCB and VFB statements. 
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section 4 
Magnetic Tape Formats and File 
Conventions 


4.1. General Information 


Maenetic tape files consist of data records that are recorded on one or more volumes 
(reels) of magnetic tape. These files are sequential files; the data records are recorded 
on tape in the order in which they are submitted, and they are read from the tape 
starting with the first record on tape and continuing with each successive record. The 
recording and reading are accomplished via a tape subsystem. Refer to Appendix A for 
the functional characteristics of the magnetic tape subsystems that are supported. 


4.2. Tape Volume and File Organization 


Consolidated data management allows you to process magnetic tape files encoded in 
Extended Binary-Coded Decimal Interchange Code (EBCDIC) as well as in the 
American National Standard Code for Information Interchange (ASCID, X3.4-1977. 
The file structure, organization, and processing specifications for ASCII magnetic tape 
files is described in the American National Standard Magnetic Tape Labels for 
Information Interchange, X3.27-1969. Both of these standards are followed when 
ASCII magnetic tape files are processed. The tape volumes (reels) can be organized as 


follows: 
e EBCDIC 
- Standard labeled 
- Nonstandard labeled 
- Unlabeled 
e ASCII 
- Standard labeled 


The paragraphs that follow explain and illustrate the different types of volume 
organization. 
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4.2.1. EBCDIC Standard Volume Organization 


A standard volume has system standard labels and required tape marks; it may also, 
at your option, contain standard user header labels and user trailer labels (UHL and 
UTL). All standard tape labels are written in blocks of 80 bytes. Data management 
assumes that the labels appear on tape in the order shown in Figures 4-1, 4-2, and 4-3, 
which illustrate the reel organization for standard labeled EBCDIC volumes with an 
end-of-file (EOF) and an end-of-volume (EOV) condition. A standard labeled EBCDIC 
volume processed by data management ends in either an EOF or an EOV label group, 
followed by two tape marks. The second tape mark indicates that no valid information 
follows. No provision is made for creating additional volume, header, or EOF/EOV 
labels on output files; if they exist on input files, data management bypasses them. 
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WITH END-OF-FILE CONDITION WITH END-OF-VOLUME CONDITION 





VOL1 label 







VOL1 label 


HDR 1 label 







HDR1 label 


HDR2 label 







HDRz2 label 


HH user header labels 
at §=©6=)| UHL1—UHL8 


user header labels 
UHL1—UHL8 










SNS 
tape mark 
S 
data 
ral blocks 


EOV1 label 


EOV2 label 


user trailer labels 


user trailer labels 
UTL1—UTL8 


UTL1—UTL8 


tape mark tape mark 


tape mark 


tape mark 





Legend 
[| Content supplied by user. 


WSS . 
NSS __ These bytes are required and generated by data management. 





These bytes are generated by data management; user supplies content for certain fields. 


Fi These bytes are generated by user's routine for processing these labels; content is at user’s option except for 
content of 4-byte labelid fields. User is limited to eight UHL and eight UTL. 


Figure 4-1. Organization for a Standard Labeled EBCDIC Magnetic Tape Volume - Single File 
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VOLT label 


HDR? label of file A 


data blocks 
of file A 


tape mark 


EOF 1 label of file A 


EOF 2 label of file A 


HDR 1 Jabel of file B 


HDR 2 label of file B 


tape mark 





data blocks 
of file 8B 


tape mark . N 
_ 


EOF 1 label of file B 


)  <- EOF2 label of file B : 


=a 


ee 





Legend 
[| Content supplied by user. 


N 
These bytes are required and generated by data management. 





These bytes are generated by data management; user supplies content for certain fields. 
Note: Assume that file B completes on this volume. 


| Figure 4-2. Organization for a Standard Labeled EBCDIC Magnetic Tape Volume - Multifile 
Volume with End-of-File Condition 
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VOL1 label 


HDR 1 label of file B 
HDR2 label of file B 
SAG 


tape mark 


data blocks 


4 ie of file B i 


tape mark 


EOF1 label of file 8 
EOF2 label of file B 


tape mark 
\ 


HDR 1 label of file C 
HDR 2 labet of file C 


tape mark 


data blocks 
of file C 


tape mark 


EOV1 !abei of file C 


EOV2 label of file C 


These bytes are required and generated by data management. 





These bytes are generated by data management; user supplies content for certain fields. 


Note: Assume that file C is not completed on reel 2, but carries over {like file B) onto another volume. If file C was 
completed on reel 2, its EOV1 and EOV2 labels shown here would be replaced with EOF] and EOF2 labels. 


Figure 4-3. Organization for a Standard Labeled EBCDIC Magnetic Tape Volume - Multifile 


Volume with End-of-Volume Condition 
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4.2.2. EBCDIC Nonstandard Volume Organization 


A nonstandard volume is any volume that contains only nonstandard labels and 
certain required tape marks. Figures 4-4 and 4-5 show the formats for EBCDIC 
nonstandard volumes. 


The optional user header and trailer labels may be of any format, length, or number 
because they are handled by a label processing routine that you supply in your 
program. 


The tape mark following the user header label is only required if you intend to use 
read-backward operations in your program or if you intend to omit label checking. It is 
not required and may be omitted if you intend to perform label checking. Normally, 
this tape mark is automatically generated by data management unless you specify 
otherwise. 


The tape mark following the data blocks is required and is automatically generated by 
data management. If user trailer labels are present, data management automatically 
generates the two required tape marks that must follow these labels. If the user 
trailer labels are not present, data management writes only one additional tape mark 
after the one following the data blocks. This second tape mark is always present when 
a file is the only file or is the last file on the volume. If the volume is a multifile 
volume, this second tape mark is overwritten by the next file placed on this volume. 
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header labels 


tape mark 


data blocks 


optional user 
trailer labels 





Legend 
a Content supplied by user. 


WN These bytes are required and generated by data management; only two tape marks follow data blocks if UTL 
: are not present. 


These bytes are generated by data management unless user specifies otherwise; required only if label 
checking is omitted or read-backward operations are specified. 





eal The presence, content, format, and number of these bytes are entirely at user’s option. 


Figure 4-4. Organization for a Nonstandard EBCDIC Magnetic Tape Volume - Single File 
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tape mark 


data blocks 
of file A 





tape mark 


optional user 
trailer labels 


optional user 
header labels 


tape mark 





data blocks 
of file B 


tape mark 


optional user 
trailer labels 


tape mark 


tape mark 





Legend 
a Content supplied by user. 


| N These bytes are required and generated by data management; only two tape marks follow data blocks of last 
AS . 
file on volume if UTL are not present. 


These bytes are generated by data management unless user specifies otherwise; required only if label 
checking is omitted or read-backward operations are specified. 


fi Presence, content, format, and number of these bytes are entirely at user’s option. 
Ss Always present; written by data management. 


Figure 4-5. Organization for a Nonstandard EBCDIC Magnetic Tape Multifile Volume 
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4.2.3. EBCDIC Unlabeled Volume Organization 


Consolidated data management can also process unlabeled tape volumes. Figure 4-6 
shows the organization for unlabeled EBCDIC volumes. 


A tape mark normally precedes the data block unless you specify otherwise. The tape 
mark following the data blocks is required on both single-file and multifile volumes 
and is automatically generated by data management. A second tape mark is always 
written by data management following the last or only file on each volume. If the 
volume is a multifile volume, this second tape mark is overwritten by the next file 
placed on this volume. 


SINGLE-FILE VOLUME MULTIFILE VOLUME 


tape mark tape mark 





data blocks 
data blocks of file A 


© N 
tape mark 





tape mark 


\ 


tape mark 





data blocks 
of file B 


\ tape mark 


tape mark 





SS 





Legend 
a Content supplied by user. 


These bytes are required and generated by data management; two tape marks follow data blocks of last file 
on volume. 


These bytes are generated by data management unless user specifies otherwise; required only when user 
specifies read-backward operations. 





@ Figure 4-6. Organization for an Unlabeled EBCDIC Magnetic Tape Volume 
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4.2.4. ASCII Standard Volume Organizations 


The American National Standard, X3.27-1978, provides for the following file sets 
(collections of one or more related files recorded on one or more volumes): 


e Single file, single volume 

e Single file, multivolume 

¢ Multifile, single volume 

¢ Multifile, multivolume 

These volume organizations are shown in Figures 4-7 through 4-10. Note that all 
ASCII tape files contain standard labels. Since data management follows the 


standard, it expects to find these labels on ASCII input files and it generates them for 
ASCII output files. 
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SINGLE FILE, MULTIVOLUME 
SINGLE FILE, SINGLE VOLUME REEL 1 REEL 2 


VOLT fabel VOL? label VOL1 label 


HDR1 label, file A HDR1 label, file A 


HDR1 label, file A 


HDR? label, file A 


HOR? label, file A 


HDR2 label, file A 


data data 
data blocks, blocks, 
blocks first last 
of part of part of 
file A file A ne 








EOF! 


EOV1 label, file A 


a 









: EOF1 label, file A 















EOV2 label, file A 


= anes | = 





EOF2 label, fiie A 


Legend 












tape mark 


2 








J Content supplied by user. 


These bytes are required and generated by: data-management. 





These bytes are generated by data management; user supplies data for certain fields. 


Figure 4-7. Organization of ASCIl Single-File, Single-Volume and Single-File, Multivolume Sets 
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MULTIFILE, SINGLE VOLUME 


VOL1 {abet 


HDA1 label, file A oe . 


HOR? label, file A ee : 


“ tape mark = 


data blocks, 
file A 
















EOF1 label, file A 





EOF2 label, file A | 





HOR1 label, file 8 





HDR2 !abe!, file B 


data blocks, 
file B 













Legend 
[J Content supplied by user. . 


NY 
These bytes are required and generated by data management. 





These bytes are generated by data management; user supplies data for certain fields. 


Figure 4-8. Volume Organization of an ASCII Multifile, Single-Volume Set 
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MULTIFILE, MULTIVOLUME 
REEL 1 REEL 2 REEL 3 










VOL1 label! 


VOL1 iabe! 







HDR1 label, file B 





HDR2 label, file B 


last part 
of 
file B 














EOF? label, file B 








EOF2 tabel, file B 


continuation 
of 





file B 





HDRi label, fiie C 





HDR2 label, file C 


file C 
{completes 
this volume) 


= -- § 


EOF1, file C 









data blocks, 
first part of 
file B 


















-EOV!1 label, file B 









EOV1 label, file B 















EOF2, file C 












EOV2 iabel, file B = EOV2 label, file B 


Legend 





tape mark 


Le 





CJ Content supplied by user. 


NY 
These bytes are required and generated by data management. 





These bytes are generated by data management; user supplies data for certain fields. 


Figure 4-9. Volume Organization of an ASCII Multifile, Multivolume Set 
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ASCII End-of-File and End-of-Volume Coincidence 


4-14 


The American National Standard, X3.27-1978, provides that whenever a volume ends 
within a file, the last block of the file is followed by an end-of-volume label (EOV1). It 
also allows for a second end-of-volume label (EOV2), which is standard in data 
management (an EQV1 label is always followed by an EOV2 label). A single tape 
mark precedes and two tape marks follow the EOV1 and EOV2 labels. 


The standard also states that no file set may be terminated by end-of-volume labels; 
consequently, provision is made for those cases where the end-of-volume and end-of- 
file coincide. In these situations, the standard provides that the labeling configuration 
shall be one of the two options shown (see Figure 4-10). Option 1 occurs when the end- 
of-tape warning mark is reached while the last block of a file is being written. Option 2 
occurs when the end-of-tape warning mark is reached after the EOF1 and EOF2 label 
groups have been started. 
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MULTIFILE, MULTIVOLUME 


OPTION 1 
REEL 1 


Me ey 


file A 
data blocks 


s-- = 


EOVI, file A 
















EOV2, file A 






tape mark 


a ff 
~~ Eo | 


REEL ncapeorninaenen nce 





VOL1 labei 
HDR1 label, file A 


| HDR2 label, file A 


= 
i 


EOF1 label, file 





| EOF2 label, file A 





2 HDRI1 label, file 


HDR2 label, file 


file B 
data blocks 


Legend 


LJ Content supplied by user. 





OPTION 2 
REEL 1 








tile A 
data blocks 


EOF, fileA — 


EOF2, file A 


HDR? label, file B 


HDR2 label, file B 


EOV1 label, file B 


EOV2 label, file B 


\ tape mark ~ 
~ tape mark 
a 


REEL 2 





VOL1 Sabet 








HDR1 label, file B 





HDR2 label, file B 


file B 
data blocks 








UP-9978 Rev. 1 


SS 
These bytes are required and generated by data management. 





3 These bytes are generated by data management; user supplies data for certain fields. 


Figure 4-10. Label Configuration Options of an ASCII Multifile, Multivolume Set when End-of- 
Volume and End-of-File Coincide 
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4.2.5. Magnetic Tape File Record Formats 


The data records on magnetic tape files nray be fixed length, blocked or unblocked; 
variable length, blocked or unblocked; or undefined. Figure 4-11 shows these formats 
as they appear on EBCDIC and ASCII magnetic tape files. Note that the formats 
illustrated in Figure 4-11 do not show the optional use of padding because it is not 
supported. If your input blocks have been padded, the I/O area in your program must 
be large enough to accommodate this padding and your program should take care of 
detecting and removing the padding characters before it processes the data. 


EBCDIC 
FIXED-LENGTH UNBLOCKED RECORD 
r-- 
| bn data record 
tee 
< D > 
< l > 


data record, data record, 





VARIABLE-LENGTH UNBLOCKED RECORD 

r-- 
block record 

bn header } length data record 





<— BH —>|<- RL —>| 
<< 2 


a ee 


Figure 4-11. Record and Block Formats for Magnetic Tape Files, ASCII and EBCDIC (Part 1 of 4) 
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EBCDIC (cont.) 


VARIABLE-LENGTH BLOCKED RECORDS 


record 


header Length, data records, data record, 





<— BH ->|<— RL | <— RL >| 
re D, es D5 ee 


UNDEFINED RECORD FORMAT 


r-- 
| bn data record 
Uy ae 
|< l > 
ASCII 


FIXED-LENGTH UNBLOCKED RECORD (FORMAT F) 


r-- 
| bsi data record 
eae 
< D > 
< l > 


data record, 








D5 > | <_____ Dz ————___+-> 


Figure 4-11. Record and Block Formats for Magnetic Tape Files, ASCII and EBCDIC (Part 2 of 4) 
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ASCII (cont.) 


VARTABLE-LENGTH UNBLOCKED RECORD (FORMAT D) 











buffer offset record 
bs1 field length data record 
(optional ) 
Les, 
< BO >1<— RL > 
<__—————— —__—_  — 0 ———— > 
< { > 


VARTABLE-LENGTH BLOCKED RECORDS (FORMAT D) 


r- 
buffer jrecord 
bsi| offset length, data record, length, data record, length data record 











field 

(optional ) 
L _ 

<— BO —>|<-RL,->4 <-RL >> <-RLz->4 

——- D, > |< D, —> |< > 

<———_—_-——_.  ————_<_—— | ue euum —m 
UNDEFINED RECUALY FORMAT CFORMAT U) : 
os e 
| bsi data record 
bee 

|<—__________. GC 

Legend 


D Record length, measured in bytes. This measure is entered in the most significant 2 bytes of the 4-byte record 
length field; the least significant 2 bytes are reserved. 


| Block length, measured in bytes. Minimum block length is 18 bytes. This measure is entered in the most 
significant 2 bytes of the 4-byte block header of EBCDIC variable-length records (blocked or unblocked); the 
least significant 2 bytes are reserved. When the buffer offset field of ASCII variable records is a 4-byte field, 
for output, data management writes the block length in it in ASCII. For input, data management assumes that it 
contains the length of the block in 4 bytes of ASCIl. 


RL Record length field of variablelength records; a 4-byte field in ASCII and EBCDIC records. Its own length is 
included in the measure inserted here. In EBCDIC records, record length is read and written in binary; in ASCIl 
records, it is recorded on tape in ASCIl, although you present it to data management in binary and process it 
in binary. 


Figure 4-11. Record and Block Formats for Magnetic Tape Files, ASCII and EBCDIC (Part 3 of 4) 
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BH Block header, a 4-byte field at the head of the block format in which all EBCDIC variable-length 
records, blocked or unblocked, appear on magnetic tape. The most significant 2 bytes contain the 
length of the block, which includes the length of the header itself; the least significant 2 bytes are 
reserved. 


bn Optional 3-byte block number in EBCDIC. May not be created for output files. Data management 
accepts the block number in EBCDIC input files, but does not process it. 


BO Buffer offset field, an optional block prefix that may be placed at the head of each block of ASCII 
variable records. Its content is recorded in ASCII; its length ranges from 0 to 99 bytes for fixed and 
undefined records and is 0 or 4 for variable records. For variable records, when its length is 4 
bytes, data management assumes that this field contains the length of the block (which includes the 
length of this field itself). 


bsi Optional 1-byte block sequence indicator for ASCII files in ASCII numeric code. May not be created 
for output files. Data management accepts the block sequence indicator in input files, but does not 
process it. 


Y The index register specified by the IOREG keyword parameter points here, to the first byte of the 
record length field of variable-length records. 


Notes: 


1. Although the American National Standard, X3.27-1969, also provides for a variable ASCII record 
with its record length specified in binary (commonly called the “V-format” record), data 
management does not support this format. 


2. | Spanned records (those extending beyond one block) are neither allowed in ASCII magnetic tape 
files (in which there must be an integral number of records per block) nor supported by data 
management tin EBCDIC tape files. 


Figure 4-11. Record and Block Formats for Magnetic Tape Files, ASCII and EBCDIC (Part 4 of 4) 


4.3. Magnetic Tape File Job Control Considerations 


The paragraphs that follow discuss the job control statements you include in your 
program execution job control stream when your program requires magnetic tape files. 
These are the DVC, VOL, LBL, and LFD statements (commonly called the device 
assignment set) and they must appear in this order in the job control stream. 


The job control stream must contain a device assignment set for each magnetic tape 
file used by your program. This set is composed of at least one DVC (device 
assignment) statement and one LFD (logical file definition) statement. The set may 
also include a VOL (volume specification) statement and a LBL (file label information) 
statement when you need them to specify certain actions and information to data 
management. 


See the Job Control Language Programming Guide (UP-9986) for the full formats of 
these statements and other details on their use. 
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4.3.1. Assigning a Tape Device to Your Job (DVC) 


The DVC statement, with which you request the assignment of a tape unit to your job, 
must be the first in the device assignment set that you need for each magnetic tape 
file. 


For the first positional parameter of the DVC statement, you specify nnn, a decimal 
number that is the logical unit number assigned to a tape device by your installation. 
The value of nnn normally ranges from 90 through 127 for tape units; however, your 
installation may have assigned other arbitrary logical unit numbers to one or more 
tape devices at system generation time. The two other specifications for the first 
positional parameter of the DVC statement (RES and RUN) are not used for magnetic 
tape files. 


Your use of the optional second positional parameter of the DVC statement depends 
on your requirements; if you omit it, none of the three options available to a data 
management user apply. One option is to specify that job control may assign an 
alternative device of the same type as specified by nnn; for this, you specify ALT. 


A second specification for this parameter, OPT, indicates that the device requested by 
this DVC statement is an. optional device, not essential to the running of the job. If you 
select this option, you must indicate in your program that the associated file is an 
optional file. 





The third specification for the second positional parameter of the DVC job control 
statement is IGNORE. You specify this form when you assign more than one logical 
file to the same tape device; that is, when your program accesses more than one of the 
files on a multifile volume. You do not specify IGNORE when you are merely using the 
same tape unit for handling the different volumes of a multivolume file in succession. 


The coding examples that follow illustrate some of the uses of the DVC job control 
statement in assigning devices to magnetic tape files. Note that the corresponding 
LFD statements, with which each DVC statement must be paired, are not shown. For 
a table of logical unit numbers and further details, refer to the Job Control Language 
Programming Guide (UP-9986). 


Examples 





// DVC 122,ALT 
// DVC 97,0PT 
// OVC 111, IGNORE 


- WN = 
. «8s #+@ 8 


Explanations 


1. Requests the assignment of any tape device to your job, for the file named in the 
accompanying LFD statement. 
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2. Requests the assignment of two tape devices of the same type for the file named 
in the accompanying LFD statement. 


3. Requests the assignment of any tape device to this job. However, this device is 
not essential to the job. The job can be run even if this device is not available. 


4. Requests the assignment of a tape device to this job. This same unit is also 
assigned to other files by LFD statements paired with identical DVC statements 
in the control stream for this job. 


4.3.2. Specifying Tape Volume Information (VOL) 


The VOL statement is required for all three types of files: standard labeled, 
nonstandard labeled, and unlabeled files. For standard labeled files, it is used to 
supply volume serial numbers (VSNs) for checking by data management. 


For nonstandard and unlabeled files, you must include the (NOV) parameter. This is 
necessary because these files do not contain VOL1 labels and therefore do not have 
VSNs. When you use a VOL statement, you insert it in your device assignment set 
immediately after the DVC statement and before the LBL statement (if used). 


Inhibiting Volume Serial Number Checking 


Normally, for a standard labeled input file, you will want data management to check 
the VSN you specified in the first positional parameter of the VOL statement against 
the VSN contained in the VOL1 label in the tape volume. This action is performed 
when your file is opened. If you want to bypass this checking, you can do so by 
specifying (NOV) following the VSN as shown in the following example: 


Example 
// VOL  ABC123(NOV) 
Explanation 


The example specifies that volume checking is not to be performed on the tape 
volume whose VSN is ABC123. 


There are other ways in which volume checking can be specified or inhibited. These 
are described in detail in 4.3.3, which describes the LBL statement, and in Table 4-1. 
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4.3.3. Specifying Tape File Label Information (LBL) 


You use the LBL statement as the next-to-last job:contro] statement in the device 
assignment set for a standard labeled tape file to provide data management with the 
information it needs for writing and checking the file header label group (HDR1 and 
HDRz2 labels) and the end-of-file label group (EOF1 and EOF2 labels) or end-of- 
volume label group (EOV1 and EOV2 labels). You must have it for volume checking; it 
has seven positional parameters, only the first of which is required. 


Specifying the File Identifier 


In the first positional parameter of the LBL statement, you must specify a file label 
that corresponds, not necessarily to the logical name of the file (by which your 
program refers to it), but to the file name that is recorded in the HDR1 label of the 
file on the volume. The file identifier for a tape file may contain as many as 17 
characters, including blanks; if it contains blanks, you enclose it in apostrophes. If you 
do not have an LBL statement for an output file, data management uses the logical 
file name (specified in the mandatory LFD statement) for the file identifier field of the 
HDR1 and EOF 1 or EOV1 labels. 


Checking and Creating Volume and File Serial Numbers 


In the second positional parameter of the LBL statement, you either specify the file © 
serial number or request data management to check the relationship between this and 
the volume serial number on an input file or to create the file serial number on an 
output file. If you specify the file serial number, it is a 1- to 6-character alphanumeric 
string identical to the volume serial number of the first volume of the file. The option 
VCHECK in the second positional parameter requests data management to create or 
check this identity in the file labels. The VCHECK parameter instructs job control to 
use the volume serial number of the first volume of the file as the file serial number. If 
you have four volumes in a file, and you only want to use the last two volumes (3 and 
4, in that order), you must specify the file serial number that is the same as the 
volume serial number of the actual first volume of the file. When the 4-volume file is 
created, you use the VCHECK parameter to assign the same file serial number to each 
volume. If you use the VCHECK parameter again, while trying to read only the third 
and fourth volumes, job contro! uses the volume serial number of the first volume 
you've coded (volume 3) as the file serial number value. Because volumes 3 and 4 were 
created with the file serial number of volume 1, the job will not run. Omitting the 
second positional parameter may inhibit the check or creation actions, depending on 
what you have specified in the VOL card and on whether the file is an input or an 
output file. Table 4-1 summarizes the combined effects of the various VOL and LBL 
statement specifications upon the actions taken by data management when a file is 
opened. 
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Table 4-1. Effects of Job Control VOL and LBL Statements on Data Management when a File Is 
Opened, Standard Labeled Tape File 





VOL Statement, 
Specification of 
Positional Parameter 1 





Unique VSN 


Unique VSN 


Unique VSN 





Unique VSN Unique FSN 
Unique VSN VCHECK 


Unique VSN 


Notes: 







LBL Statement, 
Specification of 
Positional Parameter 2 






Resulting Action by OPEN Transient 


VSN Field of 
VOL1 Label 


Input Files 


Unique FSN 


VCHECK 


Blank, or statement 
omitted 


Blank, or statement 
omitted 







Checks that VSN in 
VOL1 label is identical 
to VSN specified in 
VOL statement 


Checks that VSN in 
VOL1 label is identical 
to VSN specified in 
VOL statement 


Checks that VSN in 
VOL1 label is identical 
to VSN specified in 
VOL statement 


Creates VSN in VOL1 
label identical to the 
VSN specified in the 
VOL statement, or 
checks that VSNs are 
identical 


Creates VSN in VOL1 
label identical to the 
VSN specified in the 
VOL statement, or 
checks that VSNs are 
identical 


Creates VSN in VOL1 
label identical to the 
VSN specified in the 
VOL statement, or 
checks that the VSNs 
are identical 























Fite Serial Number 
Field of HDR1 Label 








Checks that FSN in 
HDR 1 label is identical 
to VSN in the VOL1 
label of the first volume 
of the file 


Checks that FSN in 
HDR 1 label is identical 
to VSN in the VOL1 
label of the first volume 
of the file 


No check made 


Creates FSN in HDOR1 
label identical to 
VSN in the VOL1 
label of the first 
volume of the file 












Creates FSN in HDR1 
label identical to 
VSN in the VOL1 
label of the first 
volume of the file 












Creates FSN in HDR1 
label identical to 
VSN in the VOL1 
label of the first 
volume of the file 








Pps 


1. Specifying any combination of the VOL and LBL statements other than those shown for input or output files is 
invalid and results in an error message being issued. Invalid job control specifications must be corrected and 


your job rerun. 


2. When you specify (PREP) following the VSN in the VOL statement for an output file, you may specify any of 
these three combinations in the LBL statement. Refer to 4.3.5 for a description of the data management 


automatic tape prep 
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Specifying the File Expiration Date 


To provide data management with the expiration date of a file, you specify the 
expiration date in either of the two forms provided for it in the third positional 
parameter of the LBL statement. These forms are the actual expiration date you want 
or the number of days the file is to be retained beyond its creation date. This 
information is inserted in the file HDR1 label. If you use the file retention form of this 
option, you should either specify a file creation date or rely on the default assumption 
as described in "Specifying the File Creation Date" in this subsection. If you do not 
specify a file expiration date, data management makes the expiration date the same 
as the creation date. 


Examples 
1 10 16 72 
1. y LBL FICA,A12345, 76366 
2. |// LBL FICA,B12345,R30 
Explanations 


1. Specifies that the expiration date of the tape file, whose external label is FICA 
and whose FSN is A12345, is 31 December 1976. 


2. Specifies that the tape file, whose external label is FICA and whose FSN is 
B12345, is to be saved 30 days beyond the date it is created. 


Specifying the File Creation Date 


You may specify the creation date of the file by coding the fourth positional parameter 
of the LBL statement. If you omit this parameter, data management uses the date 
stored in the job prologue. 


Specifying the File Sequence Number 


The file sequence number is not the same thing as the file serial number; you use the 
file sequence number in a multifile tape volume to indicate the sequential position of a 
file with respect to the first file on the reel. The file sequence number of the first file 
may be 0001. Data management assumes this value is specified if you omit the fifth 
positional parameter in the LBL statement, and so records it in the file HDR1 label. 


Specifying the File Generation and Version Numbers 
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You may specify a unique edition of a file by specifying its generation number in the 
sixth positional parameter of the LBL statement; the default assumption is 001. You 
may specify the version number of this generation in the seventh parameter; here, the 
default is 01. 


UP-9978 Rev. 1 





Magnetic Tape Formats and File Conventions 





4.3.4. Defining Your Logical File (LFD) 


Fach device assignment set in your job control stream must end with an LFD 
statement that specifies the logical file name-for your-file. This file name must be the 
same as the name you specified when you defined your file in your program. Job 
control allows the file name to be as many as eight alphanumeric characters. Data 
management, however, requires that the file name not exceed seven characters and 
the first character must be alphabetic. 


The file name in the LFD statement is the first positional parameter. To ensure that a 
read-only type file is not inadvertently written over, you may precede the file name in 
the LFD statement with an asterisk (*) to indicate an input only file. This indicates 
that the operator should verify that the write-enable ring has been removed from the 
tape reel. 


The second positional parameter of the LFD statement is not used in device 
assignment sets for magnetic tape files. 


The EXTEND option of the third parameter may be used on the LFD statement to 
specify that a previously created output file is to be extended (see 4.3.8). 


The coding examples that follow illustrate the uses of the LFD statement. 


Examples 





1. |// LED *YOURFLE 
2. \// LED MYFILE 
3. |// FD OUTFLE,,EXTEND 


Explanations 


1. Specifies that the logical name of the file to which this device assignment set 
pertains is YOURFLE, and that it is an input-only file. The operator should verify 
that the write-enable ring has been removed from the tape reel. 


2. Specifies that the logical name of the file to which this device assignment set 
applies is MYFILE. It is not designated as an input-only file, and no physical 
safeguard is made by the operator against its being overwritten. 


3. Specifies that the output tape file, OUTFLE, is to be extended. OUTFLE must be 


the last or only file on a single tape volume or a file that needs additional space 
on a new volume. 
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4.3.5. Preparing Tape Volumes 


4-26 


If you intend to create standard labeled tape files in your program, you must first 
prepare the tape volumes on which you intend to write your output files. This process 
consists of writing the standard VOL1, HDR1, and HDR2 labels on these tape 
volumes. There are two ways you can do this. The first way is to use the tape prep 
utility (TPREP) to prepare the volumes before they are used in your program. This is 
described in the System Service Programs (SSP) Operating Guide (UP-8841). 


The second way is to request data management to prepare the required tape volumes 
for the file at program execution time. This is accomplished by specifying (PREP) in 
the VOL statement for your file after the VSN of each volume that is to be prepped. 
When you do this, data management writes the standard VOL1, HDR1, and HDR2 
labels on these volumes when the file is opened and processing continues from that 
point on. 


Part of the information required by this tape prep facility for writing HDR1 and HDR2 
labels may be specified in the LBL statement; therefore, when you specify (PREP) on 
the VOL statement of a device assignment set, you may also include an LBL 
statement in the set (refer to 4.3.3 and Table 4-1). 


The examples that follow show how to use the VOL statement to cause data 
management to prep tape volumes at program execution time. 


Examples 
1 18 16 72 


1. | // VOL ABC789,DEFO12(PREP) 
2. | // VOL ,,,,DEFO14(PREP) 


Explanations 


1. Calls on data management to prep two tape volumes, whose VSNs are ABC789 
and DEFO12. By default, data management uses the tape density and other 
mode characteristics specified by your installation at system generation for the 
tape device specified in the DVC statement which starts this device assignment 
set. Data management uses information supplied in the accompanying LBL 
statement to write the HDR1 and HDR2 labels for the files on these volumes. 


2. Calls on data management to prep a tape volume (DEFO14), but set the volume 
sequence number (in the HDR1 label) to 4 rather than 1. The prep utility adds 
one for every comma immediately preceding the first operand to get the volume 
sequence number. Whenever you use tapes in a multivolume file environment, 
this procedure should be used because it eliminates the use of scratch volumes. If 
scratch volumes are used, the volume sequence number defaults to 1, resulting in 
a volume sequence number error condition. Even though this condition can be 
ignored, it is recommended that your volume sequence numbers be valid. 
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® 4.3.6. Specifying Mode Characteristics for Tape Volumes 


Data management does not set the mode characteristics of the tape volumes, such as 
bytes per inch (recording density), parity, and the number of tracks. These 
characteristics are usually set at system generation and all tape volumes are recorded 
with these characteristics by data management. 


If you need to use or produce a volume that does not conform to the mode 
characteristics set at system generation, you must specify this via the Mcc parameter 
in the VOL statement for this volume in the device assignment set. The following 
example shows how this can be done: 


Example 
1 19 16 v2 
// NOL MC@,ABC123 

Explanation 


This example specifies that the tape volume whose VSN is ABC123 has a 
recording density of 1600 bytes per inch and parity is odd. For full details on 
mode characteristics, refer to the Job Control Language Programming Guide 
(UP-9986). 


4.3.7. Creating Multivolume Files 


As explained in 4.3.5, you may use the VOL job control statement to specify the 
volume serial numbers (one for each tape used) of the volumes that will constitute a 
magnetic tape output file. If you have not previously prepped these tapes, specification 
of the (PREP) parameter in the VOL statement causes them to be prepped 
automatically for you as part of the job step creating the file. These procedures are 
helpful when you know precisely the size of the file and the exact number of tapes it 
requires - but this is not always the case with a new file. 


If you specify (PREP) and fill all the tapes specified in the VOL statement and have 
not completed creating your file, there is no way to complete it in this job step. An 
error message is issued (DM41 FILE SPACE IS EXHAUSTED) and your job cancels. 
In some circumstances, you do not know exactly which was the last block written to 
this tape. Therefore, you may still not be able to estimate easily how many volumes 
are needed in your next effort to create the file. In other circumstances, possibly the 
entire run has been futile. 
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Data management offers a useful facility in case you do not know the exact number of 
volumes needed for an output file. It automatically extends your file, one volume at a 
time, after the last volume specified on the VOL statement has been exhausted. It 
continues to do this until you terminate your file creation operation. This can only be 
done, however, if you do not specify the (PREP) parameter in the VOL statement. 
Automatic prepping of tapes cannot be requested at the same time the automatic 
extension feature is requested. Furthermore, if you are creating a ncnstandard tape 
file, the (NOV) parameter must be specified in the VOL statement. 


When you are creating a file under these conditions, data management issues a mount 
message to the operator for a scratch volume each time an end-of-volume marker is 
reached. This continues until you terminate the file creation operation. The message 
issued to the operator at the system console is 


MOUNT VSN=SCRATCH ON DVC xxx RIC 


When this message is displayed, the operator must mount either a preprepped tape, if 
a standard labeled file is being created, or an unprepped tape, for a nonstandard 
labeled or unlabeled file, and then reply R to the mount message to aliow the program 
to continue writing your output file but on the new volume. If a standard labeled file is 
being created, you should make enough preprepped and properly sequenced tapes 
available to allow the operator to complete the operation as requested. You must also 
furnish the operator with instructions designating the order in which the tapes are to 
be mounted. If the tapes are mounted out of sequence and are correctly preprepped 
with consecutive volume sequence numbers, the output file is created, but an error 
message indicating the out-of-sequence condition is displayed on the system console 
each time the file is read. Although these messages may not confuse you, they could 
cause other users of the file unnecessary concern. If a nonstandard labeled or 
unlabeled file is being created, your instructions should request the operator to mount 
an unprepped volume each time the mount message is displayed and somehow 
identify the order in which they are to be mounted. 


4.3.8. Extending Tape Files 


4-28 


Data management allows you to extend a standard labeled tape file provided that the 
file is not physically followed by another file on the same volume. When you extend a 
file, the record size, record format, and block size specifications of your extending 
program must be the same as those specified for the original file. Your extending 
program must also specify that the file is an output-only file. 


Both single-volume and multivolume files can be extended by specifying the EXTEND 
parameter in the LFD statement associated with the file. The EXTEND parameter 
directs data management to proceed to the end of the file when the file is opened and 
erase the end-of-file label. The extension then begins on the mounted tape unless the 
end-of-file label happens to coincide with the end-of-volume marker. If this happens, a 
mount message is issued. In either case, data management proceeds to extend your 
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file until it is closed by your extending program. If an end-of-volume condition is 
reached and there is more data to be placed on the file, data management requests the 
mounting of the next volume specified in the VOL statement for this file and 
continues extending it. 


If you think that your file extension operation will require the operator to mount 
additional tapes, you should prep the volumes you want used with the appropriate 
volume sequence numbers before you begin your file extension operation. This allows 
you to identify the tapes you want to use in the VOL statement, and eliminates the 
confusion that arises when the tape file is read and the volume sequence numbers on 
the tapes are not consecutive. Remember that you cannot request automatic prepping 
of tape volumes while you are extending a tape file. This can only be requested with a 
file creation operation. Consequently, the (PREP) cannot be specified in a VOL 
statement associated with a file extension operation. 


The following device assignment set shows how you specify the extension of a file that 
is not expected to exceed the limits of the present tape volume: 


// ove 90 

// VOL TP®1 

// LBL MASTER 

// LFD MAST, , EXTEND 


If you expect the extension to exceed the space remaining on the present volume, you 
should add the VSNs of the new tapes to the VOL statement as follows: 


// DVC 90 

// VOL 1P@1,1P@2,TPQ3,... 
7 LBL MASTER 

// LED MAST, ,EXTEND 


If you are extending a multivolume tape file, your device assignment set need only 
identify the last volume containing the file (plus any new volumes you may need), but 
you must also include the VSN of the first tape volume in the file as the second 
parameter in the LBL statement. For example, if you had a master file on tapes TP01, 
TP02, and TP03 that you wanted to extend, and you expected your extension to 
require one additional tape, your device assignment set would be as follows: 


// DVC 92 

// NOL ,,,1P03,TPO4 
// LBL MASTER, TPQ1 
// LED MAST, , EXTEND 


The first VSN (TP01) is required to identify the new tape TP04, as well as TP03, as 
being part of a file named MAST, which begins on TPO1. 
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section5 — 
Disk and Format Label Diskette Formats and 
File Conventions 


5.1. General Information 


Whenever “disk file" is used in the following discussion, it refers to both disk and 
format label diskette files. A format label diskette file is treated exactly the same as 
any other disk file. 


Disk files consist of data records that are recorded on one or more volumes (disk 
packs). These files differ from other types of files in that the data records can be 
retrieved not only sequentially but also randomly by relative record number (the 
position of a record in the file relative to the beginning of the file) or by the record key 
(a character string specified within each record to uniquely identify that record). The 
data records are retrieved or written on the disk volume via a disk subsystem. Refer to 
Appendix A for the functional characteristics of the disk subsystems that are 
supported. | 


Usually, there is more than one file on a disk volume. In order to keep track of where 
these files are located, each volume contains a volume table of contents (VTOC). Each 
file also contains system standard labels that identify and delineate it. 


5.1.1. How Disk Files Are Organized 


Disk files fall into two general categories: nonindexed and indexed. 


A nonindexed file is organized consecutively. Its records are written on the disk in the 
order in which they are presented. The records are processed consecutively in the 
same order as they appear on the disk. A nonindexed file can also be one that is 
organized relatively; each record in the file is written on the disk in a specific position 
relative to the beginning of the file. This allows any record in the file to be retrieved 
directly without processing any preceding records when the location (relative record 
number) of the record is specified. 


An indexed file contains data records and an index of the record keys. The data 
records appear on the disk in the order in which you submitted them and the index is 
arranged in ascending key order. The records can be processed sequentially or 
randomly by record key. If the records are processed sequentially, the processing 
commences with the record that has the lowest key value. For random retrieval, you 
neéd only specify’ the key of the récord you want retrieved. 
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5.1.2. Disk Access Method 


Consolidated data management uses one access method for all disk files - MIRAM 
(multiple indexed random access method}: MIRAM provides the functions that were 
previously provided by separate access methods. 


MIRAM Concepts 


MIRAM has a number of features and concepts that distinguish it from other disk 
access methods. 


e [Each data record is stored in a record slot. Record slots in MIRAM files, for either 
fixed- or variable-length records, are of uniform size and may span physical 
blocks, tracks, and cylinders as required. They may even extend from one volume 
to another (unless the file was created for processing only a single volume online 
at a time). 


¢ Data record slots are written on disk compactly as a continuous string of bytes. 


¢ The data buffer size specified in the program only determines the number of 
physical blocks that are transferred between the disk and main storage in a 
single access. 


e The string of data records can always be accessed sequentially (consecutively) or @& 
by relative record number. In addition, the data can be indexed by up to five keys; 
this causes MIRAM to build a suitable index structure for each key type in a 
partition that is separate from the data. 


e An indexed MIRAM file can be accessed by the additional random-by-key or 
sequential-by-key modes using a given key of reference, which can be changed. 


¢ Indexed MIRAM files, either multivolume or single volume, may be created by 
means of an orderly load (records submitted in ascending key order) or a 
disorderly load (records submitted in no particular key order) and they may be 
extended by appending records in either manner. MIRAM does not sort the index 
at the completion of a disorderly load, but maintains the index current on a 
record-by-record basis. 


¢ Duplicate keys are permitted. 


e Anew record is immediately available for retrieval whether it has been added to 
an indexed or nonindexed file. 


¢ Multivolume MIRAM files may be created for processing with either one volume 
online at a time or with all volumes online. They must be processed in the same 
manner as they were created. All volumes must be the same device type. 
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All programs that access a MIRAM file need not use the same data buffer size for 
input/output as was used to create the file. Those that access an indexed MIRAM 
file, however, must use the same index buffer size. 


MIRAM allows you to logically delete records in your files; that is, it allows you to 
mark records so that in subsequent processing they will be ignored. A deleted 
record count is maintained for all files created under Release 12.0 or later. This 
count will always be accurate for files created with recovery. However, for files 
without recovery, the count will show the number of deleted records at the time 
the file was last closed. 


The deleted record count is displayed on the System Utilities (SU) ‘VTP’ print. 
Files that are created with this functionality will show a valid count; that is, zero, 
or the actual count. When an accurate count is not available (for example, a file 
created prior to Release 12.0), the field will be blank. 

MIRAM always extends an existing file unless the INIT parameter is specified on 
the LFD statement. This causes initialization of the file. MIRAM does not 
recognize the EXTEND parameter on the LFD statement, and you cannot use 


EXTEND to override a program specification that calls for initialization of the 
file. 


These are the restrictions. 

- The maximum key length is 80 bytes. 

-  Nobyte of a record key may contain the hexadecimai value ‘FF’. 

- The minimum size for the index and data buffer is 256 bytes. 

- The maximum size for the index buffer is 32,512 bytes. 

- You may not mix device types within a multivolume file set. 

The two types of MIRAM files are MIRAM characteristic files and IRAM 
characteristic files. MIRAM characteristic files meet one or more of the following 
conditions: 

- Multiple keys 

- Duplicate keys permitted 

- Key change on update permitted 

- Variable file record format 


- Record control byte (RCB) 
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You may use the MIRAMCHAR SYSGEN parameter to specify MIRAM 
characteristics for all newly created MIRAM files, regardless of the file’s actual 
characteristics. For further details on the MIRAMCHAR parameter, refer to the 
Installation Guide (UP-8839). 


5.2. MIRAM File Organization 


All MIRAM files contain two partitions: the data partition, which contains the data 
records, and the index partition, which contains an index for each of the keys in your 
records. If the file is a nonindexed file, the index partition is not used; that is, no 
entries are placed in it and no space is allocated to it. If the file is indexed, entries are 
placed in the index partition and space is allocated to it. 


For indexed files, the data partition precedes the index partition. 
5.2.1. The Data Partition 


The data partition is arranged in the same way for both nonindexed and indexed files. 
It consists of a single compact string of data records that may be keyed or unkeyed. 


When data records are stored in a MIRAM file, the records are placed in uniform size 
record slots and are arranged in the same order in which you originally presented 
them. These caia records are stored in 256-byte physical sectors on your disk packs. 

Because the record slot size does not have to conform to the physical sector size, the ©} 
records may span these physical boundaries, as shown in Figure 5-1. 
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EXAMPLE 1 
PHYSICAL SECTOR 1 PHYSICAL SECTOR 2 PHYSICAL SECTOR 3 
2 2 
EXAMPLE 2 
PHYSICAL SECTOR 1 PHYSICAL SECTOR 2 PHYSICAL SECTOR 3 


EXAMPLE 3 


PHYSICAL SECTOR 1 PHYSICAL SECTOR 2 PHYSICAL SECTOR 3 


a 


Oo 
~ 


Notes: 

1. All physical sectors are 256 bytes. 

2. 1, 2,3,... nrepresent record slots. 

a: Record slots in Example 1 are approximately 190 bytes each. 
4. Record slots in Example 2 are approximately 300 bytes each. 


5. Record slots in Example 3 are approximately 70 bytes each. 


Figure 5-1. Disk (MIRAM) Data Record Slots Spanning Physical Sector Boundaries 


UP-9978 Rev. 1 9-5 


Disk and Format Label Diskette Formats and File Conventions 





Your data records may also span track boundaries, cylinder boundaries, and volume 
boundaries (except when a multivolume file is created for processing with only one 
volume online at any one time). When new records are added to a file, they are 
appended to the existing data record string; that is, they are added at the end asa 
continuation of the original string. 


The formats of the disk data records are shown in Figure 5-2. 


FIXED-LENGTH RECORDS WITHOUT KEYS 


data record 





VARIABLE-LENGTH RECORDS WITHOUT KEYS 


oO 


< 


RDW > 











Figure 5-2. Disk (MIRAM) Data Record Formats (Part 1 of 2) 
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VARIABLE-LENGTH RECORDS WITH KEYS 





Legend 


rcb 


RDW 


Ln 
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Record control byte (optional). Used to indicate that a record has been logically deleted from the file. For 
MIRAM fixed-length records, this byte is placed at the beginning of each record. For variable-length records, 
the third byte of the record descriptor word (RDW) is used as the rcb. 


Length of the logical record (RDW plus keys plus data). You specify this length as the number of bytes. For 
variablelength records, this value, expressed in binary, must be placed in the first 2 bytes of the RDW. 


4-byte record descriptor word for variablelength records. The first 2 bytes contain the logical record Jength (r) 
expressed in binary; the third byte may be used as the rcb; the fourth byte is not used. 


The starting location of record key n(n = 1 through 5) of a MIRAM file data record when the key does not start 
in the first byte of the record. L n represents the number of bytes (RDW plus data) that precede key n. The 
starting location of key n must be the same in each record. Key n must have the same length in each record 
(a minimum of 1 byte and a maximum of 80), and no byte may contain the hexadecimal value FF’. 

Slot size. All records are written into fixed-size slots. Slot size equals the record size + 1 for fixed-length 
records with an rcb; otherwise, slot size equals the record size. For variablelength records, the slot size 
equals the maximum record size. 


Padding. 


Figure 5-2. Disk (MIRAM) Data Record Formats (Part 2 of 2) 
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5.2.2. Entries in the Index Partition 


If you have keyed records, entries are placed in the index partition as these records 
are loaded into the data partition. MIRAM extracts all the keys from each record (a 
maximum of five keys is permitted) and constructs a 3-byte pointer for each of the 
keys from the file-relative record number of the position the record was written to. 
From these, it forms an index entry for each of the keys in the record and stores them 
in the index partition. The index entry for each key consists of the key plus 3 bytes 
(equal to the specified key length plus 3 bytes) and is stored in an area of the index 
partition, which is called a fine-level index. If you have three keys in each record, the 
index entry for each key is stored in a separate fine-level index; that is, the entry for 
key 1 is stored in the fine-level index for key 1, the entry for key 2 is stored in the fine- 
level index for key 2, the entry for key 3 is stored in the fine-level index for key 3, and 
so on. 


A fine-level index is not formatted for hardware search, unlike the other levels of 
index that are described subsequently. It is treated as a chain of multisector blocks 
where each sector is 256 bytes long. All entries in a fine-level index are maintained in 
ascending key order. Figure 5-3 shows a typical fine-level index block of three sectors. 


CHAIN TO NEXT 
FINE BLOCK 


FLAG BYTE 
CURRENT NUMBER OF ACTIVE BYTES av 





IS LAST SIX 
BYTES OF INDEX 


CONTROL AREA 
BLOCK 





“INACTIVE AREA 
ACTIVE ENTRIES 


TIO LOL 


CONTROL AREA 


Figure 5-3. Fine-Level Index Block 


When a fine-level index is created, another hierarchical level of index is always 
created - the coarse-level index. This is hardware searchable and is composed of 256- 
byte blocks that contain entries similar to those in the fine-level index. They differ, 
however, in that the 3-byte pointer in each coarse-level entry does not represent the 
file-relative number of a record in the data partition. Instead, it points to another 
index block at a lower level - either a fine-level block or a block in what is called a mid- 
level index. 
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Another difference is that instead of having a 6-byte control area, each coarse-level 
block uses its final byte to indicate the number of active entries. The high key of the 
block is the first one encountered by the hardware search. Both the coarse-level and 
mid-level index blocks have the same format tsee Figure 5-4): 


ACTIVE ENTRIES INACTIVE AREA 
i ee ee 


Pl FINAL 
HIGH ee 
KEY 

“* SECTOR 


Figure 5-4. Coarse-Level or Mid-Level Index Block 


5.2.3. MIRAM Index Structure 


As you know, you can specify up to a maximum of five keys for a file. For each key that 
you specify, MIRAM builds a separate index structure. In those files where you have 
more than one key, these separate index structures allow you to use any of the key 
types as the key of reference to access your data records when you subsequently use 
the file in a program. 


When MIRAM builds an index structure for your file, it creates a minimum of two 
levels of index: a fine-level index and a coarse-level index. If your file is very large, 
one or more mid-level indexes are created as needed. The fine-level index consists of 
one entry for every record in the data partition of your file. The fine-level entries are 
filed in ascending key order until an index block (256 bytes) is filled. At this time, one 
coarse-level entry is made that contains the high key entry of that filled block of the 
fine-level index. As each fine-level index block is filled, another coarse-level entry is 
made. This process continues until all your records are on file. 


The coarse-level index is automatically allocated by MIRAM. If the coarse-level index 
is filled before all your records are on file, a mid-level index is created. 
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5.2.4. Estimating Disk Space Required for an Indexed Disk File 


3-10 


You can use either cylinder or track allocation to allocate space for an indexed file. 


The following procedure allows you to estimate the number of cylinders or tracks for 
your primary allocation of disk space to an indexed file. The result is an 
approximation you can use in specifying the EXT statement in the job control device 
assignment set that allocates disk space for an indexed file to be created by your 
program. This procedure can also be used to determine the number of cylinders or 
tracks to be allocated for an indexed file that is to be generated from another file by 
the data utility program. 


The number of cylinders or tracks required for an indexed file includes those occupied 
by the data partition and the index structures for each key type in the file. To estimate 
the number of cylinders or tracks required by the file, proceed as follows: 


First, calculate D, the number of sectors required for your data records; that is, the 
data partition. 


Step 1 
D = record-length . number-of-records 
S 
where: 


S is the physical sector size. The default size is 256 for all types of disk 
subsystems. For the 8430 and 8433 disk subsystems, this value can be greater 
than 256. (See VSEC parameter in Appendix C.) 


Next, calculate B;, the number of index blocks required by your fine-level index for 
key;. 


Step 2 
Bs = number-of-records . (keylength, +3) . 4 
(256 . m) - 6 3 

where: 


The factor of 4/3 is used because the average fine-level index will be 3/4 full. 
m is the number of 256-byte sectors in the index buffer. 


Then calculate F;, the number of 256-byte sectors required by your fine-level index for 


| key;. 
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Step 3 


Repeat steps 2 and 3 as many times as necessary and then calculate F, the number of 
256-byte sectors required by your fine-level indexes for all keys in the file. 


Step 3a | 


Ty 
ul 

—a M | 

cn 


where: 
n is the number of keys in the file. 


Then perform the final calculation. This calculation, which is the sum of the data 
requirements and the fine-level index requirements, represents over 95 percent of the 
space required for an indexed file. Once this is determined, it is a simple matter to 
figure out what your space requirements are for a given file. 


As you can see, formulas are provided for cylinder allocation and for track allocation. 
You can use any formula, but track allocation should only be used for files whose space 
requirements are < 2 cylinders. 


Step 4 
Cylinder Allocation. Track Allocation 
C= F + OD T = FO 
U.N OALN UA 
or or 
C=T T=C N 
N 
where: 
C 


Is the number of cylinders to allocate to the file. 
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Is the disk dependent number of sectors per track for the data partition. 
If the physical sector size is 256 (default), use Table 5-1 for this value. If 
the VSEC parameter (see Appendix C) is used to specify a larger 
physical sector size for an 8430 or 8433 disk subsystem, the number of 
sectors per track will have to be determined. 


Is the number of 256-byte sectors required for the data partition. 


Is the number of 256-byte sectors required by all the fine-level indexes 
in the file. 


Is the disk-dependent number of 256-byte sectors per track for the index 
partition (see Table 5-1). 


Is the disk-dependent number of tracks per cylinder (see Table 5-1). 


Is the number of tracks to allocate to the file. 


Example 





Assume that you want to calculate the number of cylinders to allocate for an 
indexed disk file and the following conditions apply: 


Number of records 77,500 
Record length 512 bvtes 
Keylength, 28 bytes 
Keylengtho 30 bytes 
Sector size (data partition) 256 bytes 
Index buffer length 512 bytes 
Type of disk 8433 
¢ D = record length . number-of-records 
256 
= 512 . 77,500 
256 
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155,088 sectors for data partition. 
number-of-records . (keylength, +3) . 4 
(256 . m) - 6 3 

77,5086 . (28 +3) . 4 

(256 . 2) - 6 3 
6,331 index blocks required for the fine-level index for key,. 
m . B, 
2 . 6331 
12,662 sectors for the fine-level index for key,- 
number-of-records . (keylength, + 3) 4 

(256 . m) - 6 3 

77,500 . (30+3) . 4 

(256 . 2) - 6 3 
6,739 index blocks required for the fine-level index for key>. 
mm. Bo 


2. 6739 


13,478 sectors for the fine-level index for keys. 


“3 
= “TT 


F, + Fo 


12,662 + 13,478 


26,148 sectors for all the fine-level indexes for all keys in the file. 
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= 26,140 + 155,000 








29 . 19 33. 19 
= 295 cylinders are required for the data and fine-level indexes. 


Note: After you have calculated your disk space requirements and you proceed 
to create your file, you must provide enough volumes to hold the file. This 
must be considered because the amount of space available is not the same 
for all disk types. Refer to Table A-4 to determine how many volumes you 
will need based upon your calculations and the type of disk you intend to 
use. 


The minimum cylinder and track allocation for indexed MIRAM files is described 
in 5.2.6. 


Table 5-1. Disk-Dependent Factors for Estimating Disk Space Requirements 


U A N 
Unisys (Number of 256-byte (Number of 256-byte (Number of tracks 
Disk Subsystem |sectors per disk track |sectors per disk track {per disk cylinder) 
for index partition) for data partition) 





*Models 8-2@ only 
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5.2.5. Estimating Disk Space Requirements for a Nonindexed MIRAM File 


The following procedure allows you to estimate the number of cylinders or tracks 
required for your primary allocation of disk space to a nonindexed file. 


As you can see, formulas are provided for cylinder allocation and for track allocation. 
You can use any formula, but track allocation should only be used for files whose space 
requirements are < 2 cylinders. 


Cylinder Allocation Track Allocation 
C= D T = OD 
a A 
or or 
C = T=C N 


The calculation of D, A, and N is deseribed in 5.2.4. 


The minimum cylinder and track allocation for nonindexed MIRAM files is described 
in 5.2.6. 


5.2.6. Minimum Cylinder and Track Allocation for MIRAM Files 


Table 5-2 shows the minimum number of cylinders or tracks that are required by 
nonindexed and indexed MIRAM files. 


Table 5-2. Minimum Cylinder and Track Allocation for MIRAM Files 









| attocacion Type | | attocacion Type | 


File Type 
eee 


Nonindexed 
indexed | oe 


*n is the number of keys in the file. 
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5.3. Disk File Job Control Considerations 


The device assignment set that you use for a disk file in your program execution job 
control stream depends on how the file is being used in your program. If you are 
creating a disk file, you need a specific device assignment set for that situation, and if 
you are using an existing disk file, a different device assignment set is needed. In 
addition, you must also prepare a disk volume before you use it. These situations are 
discussed in the paragraphs that follow. 


5.3.1. Device Assignment Set for Creating a Disk File 
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The device assignment set for creating a disk file consists of the DVC, VOL, EXT, 
LBL, and LFD job control statements in that order. The DVC statement supplies the 
device number, the VOL statement supplies the volume serial number (VSN), the LBL 
statement supplies the file identifier, and the LFD statement associates the file name 
you used in your program with the disk volume. 


As you have noticed, an EXT statement is included in the device assignment set. This 
statement is required when you are creating a disk file. It is required because you 
have to allocate space for your file on the disk volume. The EXT statement describes 
your space requirements on the disk. The question of how much space is required for a 
file can be determined by using the formulas that are shown in 5.2.4 and 5.2.5. When 
you use the EXT statement, the first positional parameter specifies the access method. 
Because we are dealing with a MIRAM file, this parameter is always MI. Because this 
is the default case, this parameter can be omitted. 


The second positional parameter indicates whether or not you want the requested file 
space to be contiguous. C specifies contiguous space; it is best to specify this option 
whenever possible because an overly fragmented file may 


e Cause you to exceed the number of physical descrivtors within the VTOC that are 
needed to describe your file’s location. 


¢ Impact performance because of excessive read/write head movement. 
The third positional parameter is used to specify the number of units (tracks, 
cylinders) by which the file is to be dynamically extended if needed. If this parameter 


is omitted, the file is extended one unit at a time as needed. 


The fourth positional parameter indicates the units of allocation. CYL, for example, 
specifies allocation by cylinder and TRK specifies allocation by track. 


Track allocation is only permitted for 
e => All nonindexed MIRAM files 


¢ MIRAM characteristic indexed files (see "MIRAM Concepts” under 5.1.2) 
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The fifth positional parameter specifies the number of units needed by this file. 


The following example shows how the EXT statement is used and how it appears in 
the device assignment set: 


// DVC 58 

// NOL DSKe01 

// EXT MI,C,5,CYL,299 
// LBL DMASTER 

// LED MPAY 


In this example, we are creating a MIRAM file on a disk whose VSN is DSKO01, the 
file identifier is DMASTER, and the name of this file in our program is MPAY. The 
file requires 299 cylinders and it is to be extended dynamically 5 cylinders at a time as 
needed. 


Refer to the job control user guide for full details and formats for these statements. 
Notes: 


1, In many interactive applications, the ALLOCATE command makes it unnecessary 
to use job control statements to allocate disk file space. For more information about 
this command, see the Interactive Services Operating Guide (UP-9972). 


2. Inaremote environment, you cannot create a disk file on a host system. A disk file 
is created by programs running on a processor that owns the supporting device. 


9.3.2. Device Assignment Set for Allocating Fixed-Head Area to a File on 
the 8417 Disk 


The 8417 disk subsystem is available with a 4-cylinder fixed-head area. This allows 
faster data access because the read/write heads are fixed, rather than moveable. This 
feature significantly reduces the seek time required to locate records. 


Determining how much fixed-head area to allocate for a MIRAM file depends on the 
file size and your application. You can allocate fixed-head space to hold an entire file 
or just the index partition of an indexed file. 


To get the most from the fixed-head feature, consolidated data management controls 
the assignment of fixed-head area to an indexed MIRAM file as follows: 


e When you request fixed-head area for an indexed file, the fixed-head area is 
always assigned to the file’s index partition. 


¢ Consolidated data management only assigns fixed-head area to the data partition 


of an indexed file if you request fixed-head area for the entire file and there is 
enough fixed-head area for the data partition. 
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When you are dealing with a large index structure, it is especially useful to allocate 
fixed-head space just for the coarse-level index. (A file with five keys, for example, has 
five separate index structures. For each structure, data management assigns a coarse- 
level track. These tracks make up the coarse-level index. Using the EXT statement, 
you can allocate fixed-head area for five tracks and data management will place the 
coarse-level index in these tracks.) 


Note: Remember, you can only use track allocation for MIRAM characteristic 
indexed files. (see "MIRAM Concepts” under 5.1.2). 


To create a file in the fixed-head area, you proceed as you would for any other disk 
file. You must provide a device assignment set that consists of the DVC, VOL, EXT, 
LBL, and LFD job control statements in that order. 


Because you are dealing with the fixed-head area, the format of the DVC and EXT job 
control statements differ from those you would normally use when you are creating a 
disk file. The logical unit number in the DVC statement must be either 168 or 169, 
and the EXT statement must contain the FIX parameter. If this is not done, your file 
will not be placed in the fixed-head area. 


When you use the EXT statement, the first positional parameter specifies the access 
method. This parameter is always MI because all disk files are MIRAM files. Because 
MI is the default for this parameter, it may be omitted. 


The second positional parameter is C when dealing with contiguous file space. 


The third positional parameter is used to specify the number of units (tracks or 
cylinders) by which the file is dynamically extended if needed. If this parameter is 
omitted, the file is extended one unit at a time as needed. Remember, file space for 
dynamic extension is always acquired from the moveable-head area. Your file will 
never have any more fixed-head space than initially allocated to it. 


The fourth positional parameter is CYL when dealing with cylinders and TRK when 
dealing with tracks. 


The fifth positional parameter specifies the number of cylinders, or tracks, needed for 
the file. This can be determined by using the formulas shown in 5.2.4 and 5.2.5. If you 
specify more than four cylinders, any data that does not fit in the 4-cylinder area will 

be placed in the moveable-head area. 


The sixth positional parameter must always be FIX. 
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The following example shows how the DVC and EXT statements are used to specify 
that a file is to be placed in the fixed-head area and how they appear in the device 
assignment set: 


// DVC 168 

// NOL FDSK@1 

// EXT MI,C,,CYL,3,FIX 
// LBL FASTAC 

// LED QDATA 


In this example, we are creating a MIRAM file that is to be placed in the fixed-head 
area of an 8417 disk. The VSN is FDSKO001, the file identifier is FASTAC, and the 
name of this file in our program is QDATA. The file requires three cylinders, and it is 
to be extended dynamically one cylinder at a time as needed. 


If a file’s device assignment set contains multiple // EXT statements requesting both 
fixed- and moveable-head space, consolidated data management reserves the fixed- 
head space for the index. When all of the fixed-head space is used, any remaining 
portion of the index is placed in the moveable-head area. 


Refer to the Job Control Language Programming Guide (UP-9986) for full details and 
formats for these statements. 


_ 9.3.3. Device Assignment Set for Creating a Format Label Diskette File 
Using the Autoloader Feature of the 8420 Diskette 


The 8420 diskette subsystem is available with the autoloader feature. This allows you 
to place several volumes in a hopper, have them processed one after the other in the 
order that you placed them in the hopper, and have each one automatically ejected 
when processing is completed on that volume. (The operator must manually feed the 
first volume.) This feature is useful when you are creating a multivolume sequential 
file because it eliminates the need to mount and remove individual volumes during 
the execution of your program. 


When a file is opened, processing begins with the first volume and continues through 
each succeeding volume until the file is closed. At this point, processing is completed 
and the last volume is automatically ejected. (If the file is a single-volume file, the 
operator must eject it manually.) 


A format label diskette file is treated as a disk file; consequently, you proceed as you 
would to create any other disk file. You must provide a device assignment set that 
consists of the DVC, VOL, EXT, LBL, and LFD job control statements in that order. 


Because you are dealing with the autoloader feature, the logical unit number for the 


DVC statement must be 150 or 151. If this is not done, you cannot use the autoloader 
feature. 
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A separate VOL statement is required for each volume when you are creating a 
multivolume file. This is necessary because you must specify the VSN for each of the 
volumes that make up your file. 


A separate EXT statement is required for each volume when you are creating a 
multivolume diskette file. This is necessary because you must allocate space on each 
of the volumes that make up your file. 


The first positional parameter of the EXT statement is always MI. Because MI is the 
default for this parameter, it may be omitted. 


The second positional parameter is C when you are dealing with contiguous file space. 


The third positional parameter specifies the number of allocation units (cylinders, 
tracks) by which the volume is to be dynamically extended if needed. If this parameter 
is omitted, the volume is extended one unit at a time as needed. 


The fourth positional parameter indicates the units of allocation. CYL, for example, 
specifies allocation by track. 


Because you must use a separate EXT statement for each volume, the fifth positional 
parameter specifies the number of cylinders to be allocated to one volume in the file. 


The total nut.ver of cylinders needed for a file is determined by using the formulas 
shown in 5.2.4 and 5.2.5. 


The following example shows how the DVC, VOL, and EXT statements are used to 
specify that you are creating a multivolume file that is to be sequentially processed 
using the autoloader feature of the 8420 diskette. 


// DVC 158 

// VOL 1 

/{ EXT MI,C,, CYL, 60 
// VOL 2 

// EXT MI,C,,CYL,60 
// VOL 3 

// €XT MI,C,,CYL,55 
// LBL DKAUTO 

// LFD LODFIL 


In this example, we are creating a multivolume file that is to be sequentially 
processed using the autoloader feature of the 8420 diskette. The file is on three 
volumes whose VSNs are 1, 2, and 3, respectively. The total number of cylinders 
required for the file is 175, and each volume is to be extended one cylinder at a time as 
needed. The file identifier is DKAUTO, and the name of this file in our program is 
LODFIL. 


Refer to the Job Control Language Programming Guide (UP-9986) for full details and 
formats for these statements. 
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5.3.4. Device Assignment Set for an Existing Disk File 


The device assignment set for an existing disk file consists of the DVC, VOL, LBL, and 
LFD job control statements in that order. The EXT statement is not required because 
the file space has already been allocated. 


5.3.5. Extending an Existing Disk File 


When you extend an existing disk file, the process is essentially the same as creating 
the file; that is, your program creates the records and writes them on the disk. The 
only difference is that you are dealing with an existing file rather than creating a new 
one. Consequently, when you execute your file extension program, you must not 
include an EXT statement in the device assignment set. There is also no need to 
specify the EXTEND parameter in the LFD statement. 


5.3.6. Device Assignment Set for a Remote Disk File 


A remote disk file is one that is physically associated with a processor other than the 
one on which your job is running. | 


However, both processors must run on the same operating system. The device 
assignment set for the remote disk file requires a // DVC job control statement to 
specify the host-id parameter. 


The following example shows how job control statements are used to specify a remote 
disk file: 


// DVC 81,HOST=AB23 
// VOL D@BOB6 
// UBL FILE4 
// LFD REMOTE 
Remote file support specifications call for only 
e One host per file 
e External disk data files (that is, no library files) 
¢  Single-volume disk files 


Share requirements when using the host specifications include the following: 


e The remote file cannot be shared among programs; that is, the ACCESS 
parameter specifications SADD and UCP are not permitted. 


e Two jobs running on a file on a device that is physically associated with two local 
processors, have read-write protection if one job specifies one of the processors as 
host, and the other job specifies no host. 
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e Ifone of the processors is not declared host (and the disk file is physically 
associated with two processors), it is your responsibility to use the file in a read- 
only manner; that is, the ACCESS parameter specification is SRDO. 


For more details about disk file sharing, see 5.4. 


Note that the SIZE and VSEC parameters on the // DD control statement will be 
ignored if specified. For more information about remote file processing, refer to the 
Job Control Language Programming Guide (UP-9986) and the Distributed Data 
Processing Programming Guide (UP-8811). 


5.3.7. Preparing Disk Volumes 


All disk volumes must be prepared before data can be recorded on them. You do this 
by using the initialize disk routine (DSKPRP). This is described in the System Service 
Programs (SSP) Operating Guide (UP-8841). 


The DSKPRP routine performs a surface analysis of the disk tracks and assigns 
alternate tracks if defects are discovered. It also establishes a volume table of contents 
on the volume so that files can be placed on it. 


Note that, when you prepare a format label diskette volume, you must use a double- 
sided/double-density diskette. 


5.4. Disk File Sharing 
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A data management file is a collection of related records stored on an external 
medium. If that medium is a disk storage device, then the individual records in the 
file are directly accessible. Any given reference to the file is independent of a prior 
reference to the file. This capability gives disk files the potential of being shared 
between programs. References to the file (from different programs) may be 
independent of one another, but they are dealing with a common set of records. If 
multiple programs are sharing a file and at least one of the programs is writing 
(adding, updating, or deleting) to the file, then this may affect the other programs that 
are sharing the file. It is possible for one program to read a record and take an action 
based on the contents of that record, and then have another program update or delete 
that same record. All programs that use a particular file are potential candidates to 
use the file at the same time (share the file), but this should only be done if the 
particular applications are suited to such an environment. A determination must be 
made for each candidate program as to what its "share requirements” are. The share 
requirements reflect how a program intends to use the file (read-only use or read/write 
use) and how other programs can concurrently use the file. The means by which you © 
determine and specify the share requirements are discussed in detail in the 
succeeding paragraphs. 
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5.4.1. Logical Access Path (LAP) 


A disk file is like any other file in that it must be assigned to a program before the 
program can use it. The file must be both physically and logically assigned to the 
program. The physical assignment is performed at job initialization, and the logical 
assignment is performed when the program issues a request to data management to 
open the file. Data management creates a logical access path (LAP) to the physical 
file. Associated with each LAP to a disk file are the share requirements for the 
particular file. The logical summation of the share requirements of all LAPs to the file 
defines the share environment of the disk file. When a program no longer requires the 
disk file, it issues a request to data management to close the file. Data management 
responds by removing the LAP. This may result in altering the share environment for 
the disk file. 


Your sole responsibility is to determine what the LAP share requirements are. Data 
management automatically monitors and enforces the specified requirements. If a 
LAP is being created and its share requirements are not compatible with the share 
environment that has been established by other LAPs using the file, data 
management honors the requirements by suspending this program. The program is 
suspended at the point at which the file resource request was made and remains 
suspended until the LAP share requirements are compatible with the share 
environment. 


® Notes: 
a 


There is a limit of 48 concurrent LAPs using a lockable disk file. When the limit is 
reached, an attempt by a job (or task) to gain access to the file causes the job to be 
suspended until the LAP count drops below 48 (due to an explicit close request or 
job termination). 


2. Only one LAP can be established to a data set label diskette file at any time within 
a job step. If an attempt is made to open another data set or to use an already open 
data set, then the data management error, DM 89, occurs, indicating that the 
requested diskette drive is not available. | 


3. Multiple LAPs are permissible in a format label diskette within a job step. Format 
label diskettes are not shareable among jobs. 


5.4.2. Share Requirements 


As previously mentioned, the share requirements indicate how the LAP that is being 
created (the current LAP) intends to access the file and the type of access that it 
permits other LAPs (which would be sharing the same physical file) to have. There are 
two ways to indicate the share requirements: the ACCESS parameter and the LFD job 
control statement. 
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¢ ACCESS parameter 


If you have a BAL program, you can include an ACCESS parameter as part of the 
processing requirements that are specified in your program and are presented to 
data management when the file is opened. You can also specify the ACCESS 
parameter in a DD job control statement (see Appendix C) to override the 
program specification. If the ACCESS parameter is not specified in your program 
or in a DD job control statement, the default is ACCESS=EXC (see 5.4.3). 


If you use IMS, you can include the ACCESS parameter for a data file in the 
FILE section of the configurator. You can also specify the ACCESS parameter in 
a DD job control statement in the IMS start-up job control stream to override the 
configurator specification. If the ACCESS parameter is not specified for a data 
file in the configurator or in a DD job control statement, the default is 
ACCESS=EXC. 


If you have a program written in a higher-level language, the default case 
ACCESS=EXC always applies. If you want to specify other share requirements, 
you must include the ACCESS parameter in a DD job control statement. 


e¢ LFD job control statement 


If you prefix the logical file name specified in the LFD job control statement with 
an asterisk (*), it indicates to data management that this file is to be a "read- 
only" file. This is equivalent to specifying ACCESS=SRDO (see 5.4.3). If you use 
this asterisk facility, it overrides the ACCESS parameter regardless of whether it 
was specified in your program or in a DD job control statement. 


5.4.3. ACCESS Parameter Specifications 
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The ACCESS parameter has seven specifications for describing a file’s share 
requirements. For efficient processing, select the ACCESS parameter specification 
that most accurately describes the share requirement; if you specify a greater share 
requirement than needed, unnecessary file share processing (I/O overhead) results. 
ACCESS parameter specification SADD has the highest overhead; EXCR, SRD, and 
UCP have moderate overhead, and EXC, SRDO, and SRDF have no overhead. 


A description of each ACCESS parameter specification follows. Specifications are 
summarized in Table 5-3, following the detailed descriptions. 


ACCESS=EXC 
The LAP that declares this specification has exclusive read/write use of the file. 
When this specification is made, the file can only be shared with SRDF. 


ACCESS=SRDO 
The LAP that declares this specification is permitted to only read data from the 
file and it allows a number of other LAPs to share the file for read-only purposes. 
The SRDO specification defines a share environment for the file such that the 
participating LAPs sharing the file must specify SRDO, SRD, or SRDF. 
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ACCESS=SRDF 
The LAP that declares this specification is permitted only to read data from the 
file. SRDF is compatible ‘with all ACCESS parameter specifications, including 
EXC; however, some LAP specifications (described in the following paragraphs) 
may affect SRDF. Because of its compatibility with all ACCESS parameter 
specifications, when you use the SRDF specification to open a file, the usual 
compatibility checks are bypassed. Performance with SRDF is as good as with 
EXC and SRDO. 


The following conditions affect SRDF: 


¢ You can use SRDF for the following kinds of retrieval: UNKEYED random 
(relative record number) or sequential (consecutive) and KEYED retrieval. You 
can use KEYED retrieval as long as no other program is writing to the file and 
modifying the index (via record additions, or updates with key changes or key 
deletes). If the index is being modified when you specify SRDF, a DM24 error or 
an early EOF condition may result. 


e If another program is updating records in the file, the program with the SRDF 
specification does not always receive the updated version of all records. An SRDF 
program does not receive updated records if records have moved into the SRDF 
program I/O buffer before being updated by another program. The number of 
records held in the SRDF buffer depends on your buffer size. 


- For files created with the recovery option - records added by a program that 
opens the file after the SRDF program opens the file are not accessible to the 
SRDF program; records added before the SRDF program opens the file are 
accessible. 


- For files created without the recovery option - records added by a program 
that has the file open at the time of the SRDF open are not accessible. If the 
program adding records closes the file (thus updating the format labels) prior 
to the SRDF open, then all added records are accessible to the SRDF 
program. 


ACCESS=SRD 
The LAP that declares this specification is permitted to only read data from the 
file, but it permits other LAPs to share the file for read/write purposes. The SRD 
is a passive specification. It defines a share environment that is compatible with 
other LAPs whose share requirements are specified on the ACCESS parameter as 
EXCR, SRD, SRDO, SADD, or SRDF. The EXCR, SRDO, and SADD 
specifications are dominant specifications because they define share 
environments that rule out specific participants. 
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To illustrate this, assume that a single LAP with SRD specified is currently 
connected to the file, and another program requests to use the same disk file and 
specifies its share requirements with SRDO. Because SRDO is compatible with 

SRD, data management honors the request and creates an SRDO specification for 
the LAP. This results in a share environment that excludes LAPs that require 
write use of the file. 


Remember that the share environment is the logical summation of the share 
requirements of all the LAPs currently using the file. If the second request had 
specified EXCR instead of SRDO, the share environment would have permitted a 
single writer (LAP with EXCR specified) and multiple readers. If SADD had been 
specified instead of SRDO, the share environment would have allowed multiple 

_ writers as well as multiple readers. 


Note that a record added to a file by the writer participant (LAP with EXCR or 
SADD specified) is immediately available to the reader participant (LAP with 
SRD specified), while a record just updated by the writer may not be immediately 
available. (It may be in a data management buffer area for a time before it’s 
returned to the disk file.) If such a record is requested, the reader receives a valid 
record from the disk file but not the latest version. Also note, a writer participant 
can update a record just referenced by a reader participant. 


ACCESS=EXCR | 
The LAP that declares this specification has read/write use of the file, and it 
allows a number of other LAPs to share the file for read-only purposes. The 
EXCR specification defines a single-writer/multiple-reader share environment. 
SRD and SRDF are compatible specifications. 





ACCESS=SADD 
The LAP that declares this specification has read/write use of the file and it 
allows other LAPs to share the file regardless of whether they require read or 
read/write use. The compatible specifications are SADD, SRD, and SRDF. 


Physical data blocks are locked to a job when the job retrieves a record with 
intent to update that record or outputs a new record through a LAP with SADD 
specified. Locked data blocks are not available to other jobs when these locked 
blocks are referenced by LAPs with SADD specified. The number of blocks that 
are locked is dependent on the user’s buffer size. 


Blocks locked by input with intent to update are held until released by the 
followup update operation. This prevents two jobs from concurrently modifying 
the same physical blocks and thus avoids lost updates. 


The block lock generated by an output operation is temporary and is held only for 
the duration of the operation. This prevents two jobs from concurrently 
overwriting the same physical blocks and thus avoids lost records. 


A job that requests to lock blocks held by another job must wait until those blocks 


become available. Locked blocks, however, are always made available to jobs that 
request them for informational (read-only) purposes. & 
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Only one set of blocks can be locked to a job at any one time. An attempt to 
accumulate block locks causes the automatic release of any block locks previously 
held by the job. An attempt to modify released blocks is reported as an error. 


Two jobs using the same file through LAPs with SADD specified can concurrently 
add records to the file without losing any of the records added by either job. All 
added records are available to each job and all readers (LAPs with SRD specified) 
that may be participating. 


ACCESS=UCP 
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The LAP that declares this specification has read/write use of the file and allows 
other LAPs to share the file whether they require read or read/write use. The 
compatible specifications are UCP, SRD, and SRDF. 


With UCP specified, you accept responsibility for the data integrity of the file. 
This is because UCP (unlike SADD) doesn’t generate block locks. This enables an 
application to have multiple updates pending and then to successfully update 
those records without receiving block lock errors (DM14 TYPE=15). 


However, because block locks aren’t generated, lost updates are possible in a 
multiwriter environment. If, for example, another job is currently updating a 
record in the same physical block as your job or in adjacent physical blocks, your 
updates could be nullified or lost. (The number of adjacent physical blocks 
depends on the buffer size.) Lost updates can also account for inconsistencies 
between fields within a record. 


A DM14 TYPE=05 error message appears if you attempt to update a record that 
has been retrieved (with RCB) for update and subsequently deleted by another 
job. 


If the lost updates involved a key change, the key value associated with the lost 
update is deleted from the index. The key value of the most recent update is 
reflected in the index. 


_ Although updates can be lost, records added to a file are never lost even in a 


multiple adder environment. 


Note: _Single-volume files are locked on physical file name and serial number; 
multivolume files are locked on name only. If you attempt to open a 
multivolume file with the same physical file name (given in the LBL job 
control statement), your job won't be processed. Either of the following 
may occur: | 


¢ = File lockout results if the ACCESS specifications for both files are 
incompatible. 


¢ The error message DM68 TYPE=02 results if the ACCESS 
specifications for both files are compatible. 
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Table 5-2. Summary of ACCESS Parameter Specifications 


User Permitted 


Other LAPs 
Current LAP 


(and Compatible 


Specifications) 
pec 
= 3 


SRDF* 
SRD) 

Py 

PP 


EXCR Read/write 
a _ 
UCP Read/write Read/write (SRDF* 
SRD 
UCP) 


* See the SRDF description for an explanation of 
conditions that affect SRDF specifications. 












ACCESS 
Parameter 
Specification 



















Read/write (EXC 
SRDO 
SRDF* 
SRD 
EXCR 
SADD 
UCP) 



















Read/write (SRDO 
SROF* 
EXCR 
SADD 
UCP) 

















Read (SRDF* 
SRD) 












Read/write C(SRDF* 
SRD 
SADD) 
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Section 6 
Data Set Label Diskette Formats and File 


Conventions 


6.1. General Information 


Data set label diskette files consist of data records that are recorded on one or more 
volumes (diskettes). The data records can be retrieved sequentially or randomly by 
relative record number (the position of a record in the file relative to the beginning of 
the file). The data records are recorded and retrieved via a diskette subsystem. Data 
set label diskette files are not shareable. For details see 5.4, “Disk File Sharing.” Refer 
to Appendix A for the functional characteristics of the diskette subsystems that are 
supported. 


6.2. Data Set Label Diskette File Organization 


Data set label files are recorded on one or both sides of the diskette, depending on the 
diskette type used. The diskette type also determines the size of the fixed-length 
sectors on the diskette volume, the maximum number of files that the volume can 
contain, and the maximum number of data bytes the volume can contain. The effect of 
the diskette type is shown in Table 6-1. 
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Table 6-1. Data Set Label Diskette Characteristics 


Maximum Maximum 
Physical Number of Number of Maximum 
Sector Sectors Data Number of 
Size per Bytes per Files per 
Diskette in Diskette Diskette Diskette 
Type Bytes Volume Volume Volume 





128* 26* 1,898* or 242,944* or 19 
1,924 246,272 

256 15 1,110 284,160 19 

512 8 592 303,104 19 
Single 256 26 1,924 492,544 19 
Sided, 
Double 512 15 1,110 568, 320 19 
Density 
Double 128 26 3,848 492,544 45 
Sided, 
Single 256 1D 2,220 568,320 45 
Density 

512 8 1,184 606,208 45 
Double 256 26 3,848 985,088 45 
Sided, 
Double 512 15 2,220 1,136,640 45 


Density 





* — Applies to files written in basic data exchange (BDE) mode - IBM System/3 and Unisys 90/30 compatibility. The 
number of sectors available for BDE files is reduced to have compatibility between systems. Only tracks 1 thru 
73 are used in this mode. This is the only configuration available on the 8413 diskette subsystem. BDE diskettes 
are single sided, single density, have a logical record size < 128, fixedtength unblocked-unspanned records, 
and a file name of eight characters or less. Tracks 1 thru 74 are used for all other modes. 


Regardless of the recording mode used, the information on a data set label diskette is 
organized into two areas: the index track (track 0) on which data management writes 
the file labels, and tracks 1 thru 74 where the data records for the file are written. 


Data set label files may be either single-volume or multivolume files. In the latter 
case, the file can only be processed with one volume online at a time. 
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6.2.1. File Layout and Record Formats for Data Set Label Diskette Files 


The file layout and the record formats for data set label diskette files are shown in 
Figures 6-1 and 6-2, respectively. 


UNBLOCKED, UNSPANNED FILE 


LS1 LS2 LS3 


> < > < > 






































pS] ———__—____> |< ps2. ——_______> |< ps3, —___—_—_____> 


BLOCKED, UNSPANNED FILE 


jstors [storz | u | stors |store | u [ators fates | u | § 


LS1 LS2 LS3 

















< > < > < > 














PS1 ——_—_—_————__> |< PS2 ————_———_———> |< 





PS3. ——_—_____—__-> 








BLOCKED, SPANNED FILE 


@ fw [wm 


LS1 LS2 LS3 


>< 





71< 








> 











PS1 —— PS2 








PS3 











Legend 

LS Logical sector 

PS Physical sector 

U Unused portion of physical sector (PS-LS=U) 


Figure 6-1. Data Set Label Diskette File Layout 


UP-9978 Rev. 1 | 6-3 


Data Set Label Diskette Formats and File Conventions 


FIXED-LENGTH RECORDS 











data 

< R > 

< Ss > 
VARIABLE-LENGTH RECORDS 

r data 

< RDW > 

< R > 

< S > 
Legend 


R Length of the physical record; record descriptor word (RDW) plus data. For variableJength records, this 
value, expressed in binary, must be placed in the first 2 bytes of the RDW. 

RDW = 4-byte record descriptor word for variable-length records. The first 2 bytes contain the logical record 

length (r) expressed in binary. 

Slot size. All records are written into fixed-size slots. 

Padding. 





US 


Figure 6-2. Data Set Label Diskette Record Formats 


6.3. Data Set Label Diskette File Job Control 
Considerations 


A data set label diskette file is similar to a disk file in that a specific device 
assignment set is required in your program execution job control stream for creating a 
file and another is needed when you are dealing with an existing file. In addition, you 
also must prepare a diskette volume before you use it. These things are discussed in 
the paragraphs that follow. 
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6.3.1. Device Assignment Set for Creating a Data Set Label Diskette File 


The device assignment set for creating a data set label diskette file consists of the 
DVC, VOL, EXT, LBL, and LFD job control statements in that order. 


The DVC statement supplies the device number, the VOL statement supplies the 
VSN, the LBL statement supplies the file identifier, and the LFD statement 
associates the file name you used in your program with the diskette volume. 


The EXT statement is required when you are creating a diskette file only if the area 
(the extent) for the file was not previously allocated via the prep routine for the data 
set label diskette. (The prep routine for data set label diskette automatically allocates 
the entire diskette for one file and assigns a file identifier of DATA unless you specify 
otherwise.) The extent consists of contiguous sectors on the diskette. 


The first positional parameter of the EXT statement for a data set label diskette file is 
always MI. Because this is the default case for this statement, you can omit it if you 
choose. 


The second positional parameter must always be C since we are dealing with 
contiguous sectors. | 


The third positional parameter must always be 0 because there is no provision for 
dynamic extension with data set label diskette files. 


The fourth positional parameter must always be BLK because you are dealing with 
fixed-length sectors (blocks). This is the default case and it can be omitted if you 
choose. 


The fifth positional parameter must be in the form (bi,ai), where bi is the block size in 
bytes and ai is the number of blocks in the file. 


The following example shows how the EXT statement is used and how it appears in 
the device assignment set: 


// DVC 1308 

// VOL DSKT1@ 

// EXT MI,C,@,BLK, (80, 1000) ,NDI 
// LBL DSKTMAS 

// LED MEFILE 


In this example, we are creating a data set label file on a diskette whose VSN is 
DSKT10, the file identifier is DSKTMAS, the name of this file in our program is 
MEFILE, and there are 1,000 sectors requested for file space on this diskette. Also, by 
specifying NDI, we have indicated that the file is not a basic data exchange mode file. 
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6.3.2. Device Assignment Set for Creating a Data Set Label Diskette File 


6-6 


Using the Autoloader Feature of the 8420 Diskette 


The 8420 diskette is available with the autoloader feature. This allows you to place 
several volumes in a hopper, have them processed one after the other in the order you 
placed them in the hopper, and have each one automatically ejected when processing 
is completed on that volume. (The operator must manually feed the first volume.) This 
feature is useful when you are creating a multivolume sequential file because it 
eliminates the need to mount and remove volumes during the execution of your 
program. 


When a file is opened, processing begins with the first volume and continues through 
each succeeding volume until the file is closed. At this point, processing is completed 
and the last volume is automatically ejected. (If the file is a single-volume file, the 
operator must eject it manually.) 


You proceed as you would to create any other data set label diskette file. You must 
provide a device assigment set that consists of the DVC, VOL, EXT, LBL, and LFD job 
control statements in that order. 


Because you are dealing with the autoloader feature, the logical unit number for the 
DVC statement must be 150 or 151. If this is not done, you cannot use the autoloader 
feature. 


A separate VOL statement is required when you are creating a multivolume diskette 
file. This is necessary because you must specify the VSN for each of the volumes that 
make up your file. 


A separate EXT statement is required for each volume when you are creating a 
multivolume diskette file. This is necessary because you must allocate space on each 
of the volumes that make up your file. 


The first positional parameter of the EXT statement for a data set label diskette file is 
always MI. Because MI is the default case for this parameter, it may be omitted. 


The second positional parameter must always be C because we are dealing with 
contiguous sectors. 


The third positional parameter must always be 0 because there is no provision for 
dynamic extension with data set label diskette files. 


The fourth positional parameter must always be BLK because you are dealing with 
fixed-length sectors (blocks). This is the default case and it can be omitted if you 
choose. 


The fifth positional parameter must be in the form (bi,ai), where bi is the record size 
in bytes and ai is the number of records. 
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The following example shows how the DVC, VOL, and EXT statements are used to 
specify that you are creating a multivolume data set label diskette file that is 
sequentially processed using the autoloader feature of the 8420 diskette. 


// DVC 158 

// NOL A 

// EXT MI,C,9,BLK, (80,3000) ,NDI 
// VOL B 

// EXT MI,C,@,BLK, (80,3000) ,NDI 
// VOL C 

// EXT MI,C,@,BLK, (80,2568) ,NDI 
// LBL DSLAL 

// LED OFILE 


In this example, we are creating a multivolume data set label diskette file that is 
sequentially processed using the autoloader feature of the 8420 diskette. The file is on 
three volumes whose VSNs are A, B, and C, respectively. The data records are 80 
bytes in length and the total number of records is 8,560. The file identifier is DSAL, 
and the name of this file in our program is OFILE. Also, by specifying NDI, we have 
indicated that the file is not a basic data exchange mode file. 


Refer to the Job Control Language Programming Guide (UP-9986) for full details and 
formats for these statements 


@ 6.3.3. Device Assignment Set for an Existing Data Set Label Diskette File 


The device assignment set for an existing data set label diskette file consists of the 
DVC, VOL, LBL, and LFD job control statements in that order. The EXT statement is 
not required because the file space has already been allocated. Refer to the Job 
Control Language Programming Guide (UP-9986) for full details and formats for 
these statements. 


6.3.4. Preparing a Data Set Label Diskette Volume 
All diskettes must be prepared before data can be recorded on them. You do this by 
using the initialize disk routine (DSKPRP) as described in the System Service 
Programs (SSP) Operating Guide (UP-8841). 
The DSKPRP routine establishes the VTOC on the volume so that files can be written 


on it. This routine also establishes the recording density and that the diskette volume 
is to be used to record data set label files. 


UP-9978 Rev. 1 6-7 





section / 
Workstation Formats and File Conventions 


7.1. General Information 


A workstation is an I/O device that contains a keyboard and a video screen. 
Workstation input files consist of data records that you type in via the keyboard and 
output files consist of data records, created by your program, that are displayed on the 
video screen. Refer to Appendix A for the functional characteristics of the workstation 
subsystems that are supported. 


Workstation files can be either single-volume or multivolume files. Ifa file is a single- 
volume file, this means that one workstation (volume) is assigned to that file. If itis a 
multivolume file, this means that more than one workstation is assigned to that file. 


7.2. File Organization 


Workstation files differ from card, tape, printer, disk, and diskette files in that data 

rd cannot be permanently stored on them. This is true because a workstation data record 
exists on the input or output file only as long as it appears on the screen. Once the 
screen is cleared, the record is gone; that is, it ceases to exist physically. As you can 
readily see, a workstation file is a sequential file; that is, you present your input one 
record at a time and your output is displayed one record at a time. 


7.3. Workstation Record Formats 


Workstation records consist of alphabetic, numeric, or alphanumeric data. This data 
must consist of displayable characters. If you include any device control characters 
(hexadecimal equivalent 00 through 3F), this may cause hardware errors. A record can 
range from one character in length to the full extent of the screen. For example, if each 
line on a screen can contain 80 characters and there are 24 lines on a screen, the 
maximum record size would be 1,920 characters. 


7.4. Workstation File Job Control Considerations 


The paragraphs that follow discuss the device assignment sets that you include in 
your program execution job control stream when you use either single-volume or 
multivolume workstation files. 
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7.4.1. Device Assignment Set for a Single-Volume Workstation File 


When you use a single-volume workstation file, your device assignment set consists of 
a DVC and LFD job control statement. The DVC statement supplies the device 
number and the LFD statement associates the file name you used in your program 
with the workstation. 


The following example shows a device assignment set for a typical single-volume 
workstation file: 


// DVC 280 
// LFD DSPLY 


In this example, a workstation is assigned to the logical file named DSPLY. 


Workstation device assignment sets also require a USE job control statement 
whenever you use screen format services, menu services, or the dialog processor. 


Refer to the Job Control Language Programming Guide (UP-9986) for full details and 
format of these statements. 


7.4.2. Device Assignment Set for a Multivolume Workstation File 


When you use a multivolume workstation file, it means that you intend to use more 
than one workstation for either input or output. Although a workstation is considered 
as one volume in a multivolume file, it is a separate unit. Consequently, when you 
have a multivolume workstation file, you must indicate how many units are assigned 
to the logical file in your program. 





The following example shows the device assignment for a typical multivolume 
workstation file: 


// OVC = 206(3) 
// LFD DSPWKS 


In this example, the file DSPWKS is a multivolume workstation file that requires 
three workstations. Up to 255 workstations can be assigned to any one workstation 
file. 


Refer to the Job Control Language Programming Guide (UP-9986) for full details and 
formats of these statements. 


Nate: The user must specify the maximum number of workstations per file in job 
control; the system does nct automatically expand as more workstations are 
connected. 
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Appendix A 
Functional Characteristics of Input/Output 


Devices 


The tables in this appendix summarize the functional characteristics of the 
input/output devices that are supported by consolidated data management. 


Table A-1. Card Reader Subsystem Characteristics 


0716 Card Reader Subsystem* 


Card orientaticn Face in, with column 1 leading and row 9 down 
(80-, 66-, and 51-column cards) 


Card rate 1000 cpm 


Read technique Dual redundant, solar cell technique using phototransistors 
Column O amplifier checking 


Read modes Image mode: 160 six-bit characters per card 


Translate mode: 80 characters per card 
Three available codes: 


| 8-bit ASCII 
s 8-bit EBCDIC (required) 
Compressed code 


Hopper apace. 2400 cards 


Stacker capacity 
Normal (stacker 2) 2000 cards 
Reject (stacker 1) 2000 cards 





* Model 8 only 
continued 
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Table A-1. Card Reader Subsystem Characteristics (cont.) 


0719 Card Reader Subsystem 


Card orientation 
(80-, 66-, and 51-column cards) 


Read technique 






Face down, column 1 to left and row 9 facing away 











Two columns of photosensitive sensors and 
light-emitting diodes 
Dual redundant column amplifier checking 


Read modes Image mode: 160 six-bit characters per card 
Translate mode: 80 characters per card 
Hopper capacity 1000 cards 


Stacker capacity 
Normal 
Reject 





























1000 cards 
1000 cards 


Table A-2. Card Punch Subsystem Characteristics 













Cr 
160 cpm (28 columns only) 


Punch rate 
120 columns/second advance speed 


100 cards (auxiliary stacker) 


75 cpm (full card) 
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Table A-3. Printer Subsystem Characteristics 


0770 Printer Subsystem* 
Print speed 0770-00 0770-02 0770-04 


112 to 1435 Ipm, 213 to 2320 Ipm, 337 to 3000 Ipm, 
depending on character depending on character depending on character 
contingencies contingencies contingencies 

































337 lpm — 384 contiguous 
characters 


213 lpm — 384 contiguous 
characters 


112 Ipm — 384 contiguous 
characters 



















2000 !Ipm — 48 contiguous 
characters 


1400 lpm — 48 contiguous 
characters 


800 Ipm — 48 contiguous 
characters 













2320 Ipm — 24 contiguous | 3000 Ipm — 24 contiguous 
characters characters 


es 


120.0 
127.6 
135.2 
120+ 7.6n 


1435 Ipm — 24 contiguous 
characters 





Line advance rate 


Line advance timing 










Advance and print 














1 line 
2 lines 
3 lines 
n+ 1 line 











118+5.7n 







Full print width of 132 print positions placed anywhere on a 16.5-inch form. 
With 22-inch form, only central 13.2-inch portion can be 
used (160 print positions with feature). 


Forms advance control] Vertical format buffer 


Continuous forms with standard edge sprocket holes from 4 to 22 inches 
in width. Carbons may be attached or unattached with multicopy forms to 

a maximum of six parts. Recommended pack thickness not to exceed .0155 
inch for high quality print. 


Standard 48-character set. Any number of characters up to 384 with options. 
Horizontal spacing 10 characters per inch 


Vertical spacing 6 or 8 lines per inch, as determined by program 


* Model 8 only 


Number of print 
positions 









Form dimensions 





continued 
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Table A-3. Printer Subsystem Characteristics (cont.) 


| 0776 Printer Subsystem 


Print speed 210 to 1250 lpm depending on character contingencies: 
Available character sets Number of sets Nominal print 
| (characters/set) per band rate (lpm) 


—h oh 
MONOD A WH = 









Line advance timing Advance and print 


(number of lines) 








CON MDOah WN — 


Number of print 136 print positions (columns) : 
positions 
Forms advance rate 50 inches (127 cm) per second 
Form dimensions 4 to 18.75 inches (10.16 to 47.62 cm) wide 
1 to 18 inches (45.72 cm) long 
Horizontal spacing 10 characters per inch 
Vertical spacing 6 or 8 lines per inch, operator-selectable 


continued 


fs 
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Characteristic 


Print speed 


Line advance timing 





Number of print 
positions 


© Forms advance control 


Forms advance rate 


Form dimensions 


Horizontal spacing 


_ Vertical spacing 
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Table A-3. Printer Subsystem Characteristics (cont.) 


0789 Printer Subsystem 


180, 300, and 640 lpm, depending on character contingencies 





















Available character Number of sets Nomina! print 









sets per band rate (lpm) 
48 4 (plus 16 char) 317 
64 3 (plus 16 char) 306 
96 2 (plus 16 char) 246 
128 1 (plus 80 char) 177 





Advance and 
print 


Time five) 


1 line 40 40 
2 lines 52 52 
3 lines 64 64 
n+ 1 lines 764+12 76+12 


120 print positions (columns) by standard printer; 
132 columns by feature 


Controlled from host processor 
15 inches (38.1 cm) per second 


3 to 15 inches (7.62 to 38.10 cm) wide 
1 to 22 inches (55.88 cm) long 


10 characters per inch 


6 or 8 lines per inch, operator-selectable 


5 


Table A-4. Disk and Diskette Subsystem Characteristics 







Description 





























Characteristics 























































































































ra 8417 8418 8419 8420/8422 8430 8433 8470 
Disk Disk Disk Diskette Disk Disk Disk 
Subsystem Subsystem@ Subsystem Subsystem Subsystem(@) Subsystem©® Subsystem 
Data capacity MB (8-bit bytes) Single density Double density 
formatted 1 side 303,104@ 1 side 563,320 
2 sides 606,208 2 sides 1,136,640 
Number of disk units 2 to 8B 210 8 1 to 8 (with 1 to 8 (with 
per subsystem optional feature optional feature 
up to 16) 
Disk/diskette speed (rpm} 2800 2800 360 
Rotation period 21.5 17.6 21.5 166 16.7 16.7 16.7 
(ms/rotation} 
Track density 192 476 370 192 370 630 
(tracks/inch) 
= 
Number of cylinders 404 + 7 550 + 10 404 or 808 + 7 77 total, 75@for data 808 + 7 625 + 5 626+60 Q 
alternates alternates alternates use per diskette alternates alternates alternates roy 
surface oe | 
pe) 
Ds) 
Number of surfaces per Data 7 Data 7 © 
disk unit positioning 1 positioning 1 » 
= 
Positioning time (seek time) = 
Minimum (ms} 10 7 10 mts 
Average (ms) 30 35 27 @ 
Maximum (ms) 60 70 45 60 ao 
~” 
ot. 
Transfer rate 625 1130 628 784 Dependent on sector sequence 2,200 o 
{kilobytes/second} arrangement mn 
© 
N ae 
otes: — 
—_ 
Oo 
(1) Model 8 only = 
< 
(2) 242,944 for data set label BDE (basic data exchange) diskette file. © 
on 
Cc ; : a“ 
vu (3) 971,776 for format label diskette file. G 
wo oy 
wo . az 
~~] (4) Maximum value. Actual value is dependent on diskette type (single sided, single density; single sided, double density; double sided, single density; double 0 
a sided, double density), physical sector size (128, 256, or 512 bytes) and file type (format label! or data set label). ~ 
< <. 
. (5) In fixed 256-byte sectors, 40 sectors per track 
> ~” 
(6) 73 for format label diskette file and data set label BDE (basic data exchange) file. 75 for other data set label non-BDE files. 
(7) Only increments of 2 (2, 4, 6, 8) are supported. 
Equivalent of approximately six cylinders of available alternate sectors. 





T A9Y 8/66-dN 


LY 


Table A-5. Magnetic Tape Subsystem Characteristics 





Description 
Streaming 
} unisenvo 12° | UNISERVO 16° misenvo 20+ UNISERVO 10* UNISERVO 14* } unisenvo 10 UNISERVO 22* UNISERVO 24* Tape Drivet 
2 to 8 2to8 1 to 4 daisy-chained to 
host controller 


- — — — — 
a 7 






Tape units per subsystem 





Data transter rate 
(maximum) 
(frames per second) 











Tape speed 
(inches per second} 







































Tape direction 





























Reading Forward or Forward or Forward or Forward or Forward or Forward or Forward or Forward or Forward or 
backward backward backward backward backward backward backward backward backward 
Writing Forward Forward Forward Forward Forward Forward Forward Forward Forward 








Tape length (maximum) 
(feet) 










Tape thickness 
(mits) 







~ =~ oe ~ _ ae ol 
- a ee ee wad : ia ae 
65,535 65.535 65,535 a i 65,535 65,535 65,535 65,535 65,535 


48 60 
7? 77 


Maximum block 
size (bytes} 


Miminum block size 
(bytes) 


een 


9-track He track 7-track 
ia 


Interblock gap 
(inches) 


interblock gap time (ms) 


Le) 
> 


Gs wd 
NR 
a 

~ @ 

— Oo 








Nonstop 14.1 176 e 
Start-stop 20.1 23.6 30 
Pulse density 1600 800 1600 800 1600 on 9-track PE 1600 or 860 on 1600 or 800 on] 1600 on G-track PE 
{ppt) 800 ss 556 800 556 800 on 9-track NRZ! | 9-track PE/NA&ZI 9-track PE/NAZI 
200 


PE or NRZI PE or NRZt PE or NR2} 


NAZI 


Recording mode 


NRZI PE or NRZI PE or 

NRZ! NRZ} 
=—=— 
ce re 


* Model 8 only 
1 Provides dump or restore capability to backup data stored on nonremovable disk packs. 


5s 
8 § 
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Table A-6. Workstation Subsystem Characteristics 


Workstation Subsystem 


Characteristic Description 
Type of display Cathode ray tube (CRT) 
Number of display lines 24 plus 1 indicator 


Characters per line 


Number of units 1 to 8 


Keyboard arrangements Typewriter layout, typewriter layout with numeric and function pads, or Katakana/English 


Domestic, United Kingdom, Germany, France, Spain, Denmark/Norway, 


Character sets 





Sweden/Finland, Italy, or Katakana/English 
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Code Correspondences 


B.1. General Information 


This appendix presents a cross-reference table and several figures useful to you in 
visualizing the correspondences among the following codes commonly used in data 
processing: 

¢ Hollerith punched card code 

¢ EBCDIC (Extended Binary-Coded Decimal Interchange Code) 

¢ ASCII (American National Standard Code for Information Interchange) 

e Binary bit pattern (bit configuration) representation for an 8-bit system. 

¢ Hexadecimal representation 


¢ Compressed code for punched cards 


¢ Binary (image) mode for punched cards 


B.2. EBCDIC/ASCII/Hollerith Correspondence 


Table B-1 cross-references the correspondences between the Hollerith punched card 
code, ASCII, and EBCDIC. The table is arranged in the sorting (or collating) sequence 
of the binary bit patterns that have been assigned to the codes, with 0000 0000 being 
the lowest value in the sequence and 1111 1111 the highest. 


Note that the column headed Decimal uses decimal numbers to represent the 
positions of the codes and bit patterns in this sequence, but counts the position of the 
lowest value as the Oth (zeroth) position rather than the first. Thus, the position of the 
highest value bit pattern 1111 1111 is represented in the decimal column by 255, 
whereas it is actually the 256th in the sequence. This scheme corresponds to the 
common convention for numbering bytes, in which the first byte of a group is byte 0, 
and is convenient when you are constructing a 256-byte translation table. 


The column headed Decimal also represents the collating sequence for the EBCDIC 
graphic characters shown in the fourth column of the table; the fifth column, Hollerith 
Punched Card Code, contains the hole patterns assigned to these EBCDIC graphics. 
An empty space in the fourth column represents the position of the EBCDIC control 
character for which there is no graphic representation; the EBCDIC space character is 
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represented in the fourth column by the conventional notation SP at decimal position 
64, and the corresponding card code is "no punches.” 


The ASCII graphic characters, listed in the sixth column of Table B-1, are also in their 
collating sequence, and the hole patterns in the seventh column correspond to the 
ASCII graphics. The ASCII space character is represented by the notation SP in the 
sixth column at decimal position 32; the corresponding card code is, again, "no 
punches." The empty space in the sixth column represents the positions of the ASCII 
control characters for which there is no graphic representation. The shading in the 
ASCII graphic character column indicates where the 128-character ASCII code leaves 
off; there are no ASCII graphic or control characters that correspond to the bit 
patterns higher in collating sequence than 0111 1111 (the 128th in Table B-1). 


B.2.1. Hollerith Punched Card Code 


The standard Hollerith punched card code specifies 256 unique hole patterns in 
12-row punched cards. Hole patterns are assigned to the 128 characters of ASCII and 
to 128 additional characters for use in 8-bit coded systems. These include the EBCDIC 
set. Note that no sorting sequence is implied by the Hollerith code itself. 


B.2.2. EBCDIC 


EBCDIC is an extension of Hollerith coding practices. It comprises 256 characters, © 
each of which is represented by an 8-bit pattern. Table B-1 shows the EBCDIC graphic 
characters only; the EBCDIC control characters are not indicated. 


B.2.3. ASCII 


ASCII comprises 128 coded characters, each represented by an 8-bit pattern, and 
includes both control characters and graphic characters. Only the latter are shown in 
Table B-1. ASCII is used for information interchange among data processing 
communication systems and associated equipment. 
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0 
1 
2 
3 
4 . 
S 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
14 


Code Correspondences 


Table B-1. Cross-Reference Table: EBCDIC/ASCII/Hollerith 


EBCDIC 


0000 0000 
0000 0001 
0000 0010 
0000 0011 
0000 0100 
0000 0101 
0000 0110 
0000 0111 
0000 1000 
0000 1001 
0000 1010 
0000 1011 
0000 1100 
0000 1101 
0000 1110 
0000 1111 
0001 0000 
0001 0001 
0001 0010 
0001 0011 


0001 1110 
0001 1111 
00710 0000 
0010 0001 
0010 0010 
0010 0011 
0010 0100 
0010 0101 
0010 0110 
0010 0111 
0010 1000 
0010 1001 
0010 1010 
0010 1011 


0010 1101 
0010 1110 
0010 1111 
0011 0000 
0011 0001 
0011 0010 
0011 0011 
0011 0100 
0011 0101 
00110110 


EBCDIC 
Graphic 
Character 


Hollerith 
Punched Card Graphic 


Character 


12-0-9-8-1 
12-9-1 
12-9-2 
12-9-3 


12-9-8-7 
12-11-9-8-1 
11-9-1 
11-9-2 
11-9-3 


11-0-9-8-1 
0-9-1 


12-11-0-9-8-1 
9-1 





Hoilerith 
Punched Card 
Code 


12-0-9-8-1 
12-9-1 
12-9-2 
12-9-3 


12-9-8-7 
12-11-9-8-1 
11-9-1 
11-9-2 
11-9-3 


No punches 
12-8-7 
8-7 
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Table B-1. Cross-Reference Table: EBCDIC/ASCII/Hollerith (cont.) 


EBCDIC psc 


EBCDIC Hollerith ASCII Hollerith 
Graphic Punched Card Graphic Punched Card 
Character Code Character Code 
































































































55 37 0011 0111 
56 38 0011 1000 
57 39 0011 1001 
58 3A 0011 1010 
59 3B 0011 1011 ; 
60 3C 0011 1100 9-8-4 < 
61 3D 0011 1101 9-8-5 : 
62 3E 0011 1110 9-8-6 2 
63 3F 0011 1111 9-8-7 ? 
64 40 0100 0000 No punches @ 
65 41 0100 0001 A 
66 42 0100 0010 B 
67 43 0100 0011 c 
68 44 0100 0100 D 
69 45 0100 0101 E 
70 46 0100 0110 F 
71 47 0100 0111 G 
72 48 0100 1000 H 
73 49 0100 1001 
74 4A 0100 1010 J 
75 4B 0100 1011 K 
76 4C 0100 1100 L 
77 4D 0100 1101 M 
78 4E 0100 1110 N 
79 4F 0100 1111 O 
80 50 0101 0000 12 P 
81 51 0101 0001 12-11-9-1 Q 
82 52 0101 0010 12-11-9-2 R 
83 53 0101 0011 12-11-9-3 S 
84 54 0101 0100 12-11-9-4 T 
85 55 0101 0101 12-11-9-5 U 
86 56 0101 0110 12-11-9-6 V 
87 57 0101 0111 42-11-9-7 W 
88 58 0101 1000 x 
89 59 0101 1001 Y 
90 5A 0101 1010 Z 
91 5B 0101 1011 [ 
92 5C 0101 1100 x 
93 5D 0101 1101 } 
94 5€ 0101 1110 /\ 
95 5F 0101 1111 = 
96 60 0110 0000 
97 61 0110 0001 a 
98 62 0110 0010 b 
99 63 0110 0011 c 
| 100 64 0110 0100 d 
! 401 65 01100101 ‘ 
; 102 66 0110 0110 f 
| 103 67 01100111 
68 0110 1000 h 
69 0110 1001 
6A 0110 1010 
6B 0110 1011 k 
6C 0110 1100 
6D 0110 1101 m 
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Table B-1. Cross-Reference Table: EBCDIC/ASCll/Hollerith (cont.) 


EBCDIC 


EBCDIC Hollerith ASCII Holterith 
Graphic Punched Card Graphic Punched Card 
Character Code Character Code 


0110 1110 
0110 1111 
0111 0000 
0111 0001 
0111 0010 


0111 0011 
01114 0100 


01110101 
01110110 
0111 0111 


0-8-6 

0-8-7 
12-11-0 
12-11-0-9-1 
12-11-0-9-2 


12-11-0-9-3 
12-11-0-9-4 


12-11-0-9-5 

12-11-0-9-6 

12-11-0-9-7 

12-11-0-9-8 

8-1 

8-2 

8-3 

8-4 

0111 1101 ‘ . 11-0 

0111 1110 11-0-1 
0111 1111 - 12-9-7 
1000 0000 11-0-9-8-1 
1000 0001 0-9-1 
1000 0010 
1000 0011 
1000 0100 
1000 0101 
1000 0110 
1000 0111 
1000 1000 
1000 1001 
1000 1010 
1000 1011 
1000 1100 
1000 1101 
1000 1110 
1000 1111 
1001 0000 
1001 0001 
1001 0010 
1001 0011 
1001 0100 
1001 0101 


} + 


12-0-8-4 0-9-8-4 
12-0-8-5 12-9-8-1 
12-0-8-6 12-9-8-2 
12-0-8-7 11-9-8-3 
12-11-8-1 12-11-0-9-8-1 


12-11-6 
12-11-7 
12-11-8 
12-11-9 
12-11-8-2 
12-11-8-3 
12-11-8-4 
12-11-8-5 
12-11-8-6 
12-11-8-7 





a 
b 
Cc 
d 
e 
f 
h 
! 
j 
k 
t 
m 
n 
O 
p 
q 
if 


continued 
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EBCDIC 


1010 0000 
1010 0001 
1010 0010 
1010 0011 
1010 0100 
1010 0101 
1010 0110 
10100111 
1010 1000 
1010 1001 
1010 10710 
1010 1011 
1010 1100 
1010 1101 
1010 1110 
1010 1111 
1011 Q000 
101711 Q001 
1011 0010 
1011 0011 
1011 0100 
+411 0101 
1011 0710 
1011 0111 
1011 1000 


1011 1110 
1011 1111 
1100 0000 
1100 0001 
1100 0010 
1100 0011 
1100 0100 
1100 0701 
1100 0110 
1100 0111 
1100 1000 
1100 1001 
1100 1010 
1100 1011 
1100 1100 
1700 1101 
1100 1110 
1100 1117 
1101 0000 
1101 0001 


EBCDIC 
Graphic 
Character 


Holterith 


Punched Card 


Code 


11-0-8-7 
12-11-0-8-1 
12-11-0-1 
12-11-0-2 
12-11-0-3 
12-11-0-4 
12-11-0-5 
12-11-0-6 
12-11-0-7 
12-11-0-8 
12-11-0-9 
12-11-0-8-2 
12-11-0-8-3 
12-11-0-8-4 
12-11-0-8-5 
12-11-0-8-6 
12-11-0-8-7 
12-0 

12-1 

12-2 


12-8 
12-9 
12-0-9-8-2 
12-0-9-8-3 
12-0-9-8-4 
12-0-9-8-5 
12-0-9-8-6 
12-0-9-8-7 
11-0 
11-4 


Table B-1. Cross-Reference Table: EBCDIC/ASCII/Hollerith (cont.) 


ASCII 
Graphic 


Character 





Hollerith 


Punched Card 


Code 


12-0-9-6 
12-0-9-7 
12-0-9-8 
12-8-1 
12-11-9-1 
1241-99 
12-11-9-3 
12-11-9-4 
12-11-95 
12-11-9-6 
12-11-9-7 
12-11-9-8 
14-8-1 
11-0-9-2 
11-0-9-3 


0-8-1 
12-11-0 
12-11-0-9-1 
12-11-0-9-2 
12-11-0-9-3 
12-11-0-9-4 
12-11-0-9-5 
12-11-0-9-6 
12-11-0-9-7 
12-11-0-9-8 


12-0-8-6 

12-0-8-7 

12-11-8-1 
12-11-8-2 
12-11-8-3 
12-11-8-4 
12-11-8-5 
12-11-8-6 
12-11-8-7 
11-0-8-1 
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1110 0000 
1110 0001 
1110 0010 
1110 0011 
1110 0100 
1110 0101 
1110 0110 
1110 0111 
1110 1000 
1110 1001 
1110 1010 


1110 1011 
1110 1100 


1110 1101 
1110 1110 
1110 1111 





EBCDIC 
Graphic 
Character 


K 
L. 
M 
N 
S 
+ 
V 
W 
X 
Y 
Z 
0 
1 
2 
3 
4 
5 
6 
7 
8 
9 


Hollerith 
Punched Card 
Code 


11-7 

11-8 

11-9 
12-11-9-8-2 
12-11-9-8-3 
12-11-9-8-4 
12-11-9-8-5 
12-11-9-8-6 
12-11-9-8-7 
0-8-2 


0-6 
0-7 
0-8 
0-9 
11-0-9-8-2 
11-0-9-8-3 
11-0-9-8-4 
11-0-9-8-5 
11-0-9-8-6 
11-0-9-8-7 


-) 


OOoOny DAP WN — 


12-11-0-9-8-2 
12-11-0-9-8-3 
12-11-0-9-8-4 
12-11-0-9-8-5 
12-11-0-9-8-6 
12-11-0-9-8-7 
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Table B-1. Cross-Reference Table: EBCDIC/ASCII/Hollerith (cont.) 


ASCH 
Graphic 
Character 


Hollerith 
Punched Card 
Code 


11-0-8-7 
12-11-0-8-1 
12-11-0-1 
12-11-0-2 
12-11-0-3 
12-11-0-4 
12-11-0-5 
12-11-0-6 
12-11-0-7 
12-11-0-8 
12-11-0-9 
12-11-0-8-2 
12-11-0-8-3 
12-11-0-8-4 
12-11-0-8-5 
12-11-0-8-6 
12-11-0-8-7 
12-0-9-8-2 
12-0-9-8-3 
12-0-9-8-4 
12-0-9-8-5 
12-0-9-8-6 
12-0-9-8-7 
12-11-9-8-2 
12-11-9-8-3 
12-11-9-8-4 
12-11-9-8-5 
12-11-9-8-6 
12-11-9-8-7 
11-0-9-8-2 
11-0-9-8-3 
11-0-9-8-4 
11-0-9-8-5 
11-0-9-8-6 

11 -0-9-8-7 
12-11-0-9-8-2 
12-11-0-9-8-3 
12-11-0-9-8-4 
12-11-0-9-8-5 
12-11-0-9-8-6 
12-11-0-9-8-7 
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B.3. Other Card Codes 


There are three other card coding systems that can be handled by data management: 
compressed code, column binary (image) code, and 96-column code. 


B.3.1. Compressed Card Code 


Figure B-1 indicates the construction of the compressed card code; each card column is 
represented by an 8-bit pattern in 1 byte of main storage. 


—_ COLUMN PUNCH POSITIONS 


MAIN STCRAGE 
4 5 § 7 BYTE 
BIT POSITIONS 





Note: Punch positions 1 through 7 are indicated in bits 1 through 3, according to the following table: 


Punch 
Rows 1 Thru 7 





Figure B-1. Compressed Card Code 


B-8 UP-9978 Rev. 1 





Code Correspondences 





B.3.2. Column Binary (Image) Code 


Figure B-2 indicates the construction of this code. Note that each card column requires 
two bytes of main storage; an I/O area of 160 bytes is required for an 80-column card. 


COLUMN PUNCH POSITIONS 


2 
3 
4 
5 
6 
7 
8 
9 





Pon 2 Spas Pee | pes (ae ee 


DATA BYTE 0 DATA BYTE 1 


Note: Bits O and 1 are cleared to zeros on an image read. 


Figure B-2. Column Binary (Image) Card Code 
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Appendix C 
DD Job Control Statement Processing 


C.1. General Information 


The DD job control statement can be used in your program execution job control 
stream to temporarily change certain file parameters at run time. The changes are 
effective only during the execution of the job. If a permanent change is desired, you 
must change your source program. The Job Control Language Programming Guide 
(UP-9986) describes the format and placement of the DD job control statement. 


C.2. DD Job Control Statement Parameters 


Table C-1 summarizes the DD job control statement keyword parameters you can use 
to temporarily change your file parameters. If you specify a keyword parameter that is 
not allowed for the particular type of file, the specification is ignored. 


Table C-1. Allowable Keyword Parameters for the DD Job Control Statement 


Format Label Data Set Label 
Keyword Diskette/Disk Diskette Tape Card 

















— 
_ 
mae 
7 
_. 
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Table C-1. Allowable Keyword Parameters for the DD Job Control Statement (cont.) 


Format Label Data Set Label 
Diskette/Disk Diskette Tape 







* Be careful when specifying this keyword parameter. If the program accessing the file is dependent on predefined 
(e.g., compile time) file or processing characteristics, it may not be prepared for such a change at execution 
time. You may get unexpected results unless the program is a user-written BAL program prepared for this type 
of specification change or if the user documentation for the product explicitly states that this specification can 
be changed at execution time. 


Legend 


X Allowable keyword 
V_ Applies to nonsectorized disk devices only 


C.2.1. Record Format (RCFM) 
This keyword parameter specifies the record format. 


RCFM=F IXUNB 
Specifies fixed-length unblocked records. 


RCFM=F IXBLK 


Specifies fixed-length blocked records. This specification is invalid for card and 
printer files. 
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RCFM=UNDEF 
Specifies undefined records. 


RCFM=VARUNB 
Specifies variable-length unblocked records. 


RCFM=VARBLK 


Specifies variable-length blocked records. This specification is invalid for card 
and printer files. 


C.2.2. Data Buffer/Block Size (BKSZ) 


This keyword parameter specifies the size of the data I/O buffer. 

BKSZ=n 
Specifies the size of the buffer in bytes. If the full size specified cannot be used, it 
will be automatically rounded down to an appropriate size. 

The following is device-dependent information regarding block/buffer size: 


DISK/FORMAT LABEL DISKETTE/DATA SET LABEL DISKETTE 


The following algorithm determines the minimum allowable buffer size in 
logical sectors 


S/LSS=N and R 


where: 


Is the slot size. The slot size equals the record size + 1 for files with an 
RCB and fixed-length records. Otherwise, the slot size equals the record 
size. 

LSS 

Is the logical sector size. For disk and format label diskette files, the 
logical sector size is equal to the physical sector size. For the data set 
label diskette, the logical sector size is: 
¢ equal to the record size if records are unblocked and unspanned. 


¢ nxrecord size if records are blocked and unspanned. 


¢ physical sector size if records are blocked and spanned. 


Is the number of full sectors per slot. 
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Is the remainder. 


The minimum allowable buffer size in logical sectors is 


N ifR=0. 
N+1 if R divides evenly into LSS. 


N+2 otherwise 


To determine n, multiply the minimum allowable size in sectors by LSS. 


TAPE 


The buffer size is related to the record size (RCSZ) and record format 
(RCFM) specifications. The following guidelines apply for certain record 
formats: 


e For variable-length blocked records 


BKSZ must accommodate the largest block size in the file Gncluding 
block and record descriptor words). 


e For variable-length unblocked records 


BKSZ must accommodate the largest record size (including block and 
record descriptor words). 


e For fixed-length unblocked or blocked records 


BKSZ must accommodate either record size or record size x blocking 
factor. 


PRINTER 


CARD 


The buffer size determines the record size. For variable-length or undefined 
records, BKSZ is the length of the longest record (including block and record 
descriptor words for variable records). For programs using embedded control 
characters, BKSZ is n+1, where n is the length of the longest record to be 
printed. 


The buffer size determines the record size. For variable-length unblocked 
records, BKSZ is the length of the longest record (including block and record 
descriptor words). When using binary mode, BKSZ is double the maximum 
record size. 
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C.2.3. Record Size (RCSZ) 


This keyword parameter specifies the record size. 
The following is device-dependent information regarding record size: 
DISK/FORMAT LABEL DISKETTE/DATA SET LABEL DISKETTE 
RCSZ specifies the length of each record in bytes. Since variable-length 
records are written in fixed size slots, RCSZ is the slot size (including the 
record descriptor word). 
TAPE 


RCSZ specifies the length of each record in bytes and is valid only in fixed- 
length record format. 


C.2.4. Key Length (KLENn) 


This keyword parameter specifies key lengths for an indexed file. 
KLENn=L 


Specifies the length of up to five keys, when n is from 1 to 5, inclusive, and L 
is from 1 to 80 bytes. 


C.2.5. Key Location (KLOCn) 


This keyword parameter specifies key locations for an indexed file. 
KLOCn=L 
Specifies the location of up to five keys, when n is from 1 to 5, inclusive, and 


L is the number of bytes (including the record descriptor word for variable 
length records) in the record preceding the key. 


C.2.6. Index Buffer Size (INDS) 


This keyword parameter specifies the index I/O buffer size. 
INDS=n 


Specifies the buffer size, where n is the number of bytes up to a maximum of 
32,512 bytes and must be a multiple of 256. 
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C.2.7. Initial Space Allocation Percentages (SIZE, SIZE1, SIZE2) 


CDM uses the file’s record size and key size to estimate the ratio of data partition to 
index partition requirements. CDM uses this ratio to determine the percentages for 
initial space allocation of the data and index partitions. The percentages minimize the 
number of extent table entries that are required. This reduces the possibility of 
running out of extent table entries, resulting in fewer DM45 errors. 


Prior to this release, you specified SIZE=AUTO on the file’s DD JCL statement to 
allocate the percentages; now, allocation is performed automatically. If you specify 
SIZE=AUTO, it is ignored. The index partition is guaranteed to receive part of the 
initial allocation. Except for very small allocations (one, two, or three cylinders), part 
of the initial allocation is not assigned and is available for logical extensions. 


The accuracy of the calculated percentages depends on the size of the file, the effects 
of roundoff, and how the file is loaded. For more efficient use of space in the index 
partition, load records in ascending key sequence, rather than in unordered key 
sequence. If the calculated percentages exhaust the extent table or result in wasted 
disk space, use the SIZE1 and SIZE2 parameters to specify explicit percentages for 
CDM to use. 


SIZE1=n SIZE2=m 
Specify both parameters: n represents the percentage to be used for the data 
partition and m represents the percentage to be used for the index partition. 
Their total must not exceed 100. 


These specifications are effective only at file creation time; they are ignored 
if specified at other times. You create a file by 


e Loading a newly allocated file 
or 
e Reloading (recreating) a file by using the INIT job control specification 


If you used SIZE parameters to create a file, respecify them when you reload 
a file by using the INIT specification. 


C.2.8. File Sharing Characteristics (ACCESS) 


C-6 


This keyword parameter specifies the disk file sharing characteristics. The 
characteristics indicate whether or not multiple logical access paths (LAPs) can access 
the physical file at the same time and the type of processing (read and/or write use) 
that each LAP can perform. See 5.4 for detailed information on disk file sharing and 
the ACCESS parameter. 
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C.2.9. Variable Sector Support (VSEC) 


Both the data and index partitions specify a fixed sector size of 256 bytes. This is 
required for the sectorized devices (8416, 8417, 8418, 8419, and 8470 disk subsystems) 
which are formatted for a 256-byte sector. The selector channel devices (8430 and 
8433 disk subsystems) have no such constraint. However, they are preformatted when 
the file is opened to accept the 256-byte sector size. This sectorization requires 
hardware overhead and thus decreases the effective capacity of the disk. 


Variable sector support eliminates the problem. It allows you to create a disk file with 
a data partition physical sector size (PSS) that is larger than 256 bytes on the selector 
channel devices. Because the hardware overhead remains constant, the use of the 
larger PSS increases the effective capacity of the disk. 


This keyword parameter is only valid at file creation time. It is not required for 
selector channel devices and is ignored if specified at other times. If it is specified for a 
sectorized device, it is ignored. 


VSEC=n : 
Specifies the PSS where n is the size in bytes. To obtain the maximum 
benefit, n should always be a multiple of slot size. 


VSEC=YES 
Specifies that the PSS is to be automatically computed when the file is 
r opened. The computed PSS will be the largest multiple of slot size. 


Slot size is determined as follows: 


e For a file with fixed-length records that contain an RCB, the slot size 
- equals record size + 1. 


¢ For other files, the slot size equals record size. 


C.2.10. File Recovery Support (RECV) 


When you perform operations such as adding or deleting records from a keyed file or 
updating records with a key change, the physical file structure changes constantly 
during program execution. If your program completes its run and the file is 
successfully closed, the file limits information contained in the file labels is updated. 


If a system failure occurs, the file is not closed and the file limits information is not 
updated. A nonindexed file reverts to the state it was in before the file was opened, 
and any records added during the run are lost. The effect on an indexed file is more 
serious; the file’s index may become compromised, and it is impossible to determine 
whether or not this has happened. DM24 or DM339 errors or premature end of file are 
indications that the index is compromised, but they may not appear immediately. 
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File recovery support eliminates these problems by writing the current file limits 
information to disk (the first sector of the data partition, PCA1) after each function 
that changes the limits information, such as record addition, keyed deletion, or update 
with key change. You should request recovery for your files, especially indexed files, 
because it saves you the inconvenience of rebuilding files and getting unexpected 
program errors. There is only a small overhead cost incurred on the functions that 
change file limits information. 


The recovery facility is activated when the file is successfully closed, after file creation. 
If a system failure occurs during file creation, the file will have to be reloaded, because 
recovery was never activated. This ensures that no overhead is incurred during file 
creation. There is no overhead on read, update without key change, or nonindexed 
delete functions, regardless of when they occur. 


When recovery is active for a file, and a system stop occurs 


e Anonindexed file is recovered automatically. The file limits information reflects 
all of the records that were in the file at the time of the stop, and no records are 
lost. 


e Ifthe file is indexed, and CDM is in the middle of an index manipulation when 
the stop occurs, the index is compromised. The following error message appears 
the next time a program attempts to open the file: 


DM66 FILE INACCESSIBLE TYPE=01 


e If you do not receive this error on the first attempt to open the file after the stop, 
the file is totally recovered, the index is not compromised, and no records are lost. 
If you receive this error, use the RECV=FCE specification to open the file strictly 
to recreate it. 


e Note that a VTOC print (SU VTP) reflects the correct number of records. The stop 
prevents label update, but correct information is maintained in the recovery 
block. SU VTP extracts information from the labels and the recovery block. 


Use either the DMRECV SUPGEN parameter or the RECV DD JCL parameter to 
request recovery support. DMRECV lets you specify what kind of files will be created 
with recovery. 


¢ DMRECV=YES - create all data files (except temporary files prefixed $SCR or 
$JOB, or system files prefixed with $Y$). 


¢ DMRECV=INDEX - create only indexed data files (except temporary files 
prefixed $SCR or $JOB, or system files prefixed with $Y$). 


¢ DMRECVENO - create no files. 
You can override these specifications on a file basis (except temporary files prefixed 


with $SCR or $JOB) by using the RECV parameter on the DD JCL statement. See the 
Installation Guide (UP-8839) for details on the DMRECV parameter. 
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RECV=YES 
Creates the file with recovery support. It is not necessary to use this 
specification if the DMRECV parameter is set to request recovery for the file 
type in question. 


This specification is effective only at file creation time; it is ignored if you 
specify it at other times. When you recreate a file by using the INIT 
specification, respecify this parameter if you used it to create the file the first 
time. 


RECV=LOAD 
Creates the file with recovery support and activates the recovery facility 
during file creation. Use this specification if you want to activate recovery 
when you load the file. 


This specification is effective only at file creation time; it is ignored if you 
specify it at other times. When you reload the file using the INIT 
specification, you must specify this parameter again if you used it to create a 
file. 


RECV=NO 
Creates the file without recovery support. Use this specification when you 
use the SUPGEN parameter DMRECV=YES or DMRECV=INDEX and you 
do not want recovery for this file. 


This specification is effective only at file creation time; it is ignored if you 
specify it at other times. When you reload the file by using the INIT 
specification, respecify this parameter if you used it to create a file. 


RECV=FCE 
Ignores the compromised file condition; you will not receive a DM66 
TYPE=01 error. Use this specification only when you want to open a 
compromised file to read the data partition (and not the index) to recreate 
the file. 


RECV=OF F 
Deactivates the recovery facility during this job run. The recovery block will 
not be updated after each function that changes the file limits information. If 
the file is indexed and the file is not successfully closed (that is, system stop), 
you will receive a DM66 TYPE=01 error message the next time a program 
tries to open the file. For nonindexed files, added records will be lost. 


This specification is effective only for ACCESS specifications of EXC or 
EXCR; it is not supported for ACCESS specifications of SADD or UCP. You 
can use this specification to avaid recovery overhead where, if the system 
stops, the file would be backed up anyway. 
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C.2.11. One Volume Online at a Time (VMNT)} 


This keyword parameter specifies whether or not a file is to be processed with only 
one volume online at a time. 


VMNT=NO 
Specifies that the file is to be processed with all volumes online. A file that is 
created in this manner must always be processed in this manner. Random 
operations are permitted. 


VMNT=ONE 
Specifies that the file is to be processed with only one volume online at a 
time. A file that is created in this manner must be processed in this manner. 
Nonkeyed random operations or keyed random output operations are not 
permitted. 


C.2.12. Record Control Byte (RCB) 


This keyword parameter specifies whether or not a record control byte (RCB) is 
present in each record. 


RCB=YES 
Each record contains an RCB. If the records are fixed length, the RCB is 
appended to the front of each record. If the records are variable length, the 
third byte in the 4-byte overhead is used as the RCB. The presence of RCBs 
allows you to logically delete records from the file by marking them as void 
records. The records are not physically removed from the file. The marking 
process consists of setting the high order bit in the RCB. 


In addition, the presence of RCBs also provides the following: 


e Ifyou are retrieving records sequentially, the deleted records are 
skipped over. 


¢ Ifyou are retrieving records randomly and your search argument 
specifies the key or relative record number of a deleted record, it results 
in a no-find error condition. 


e Ifyou are outputting records randomly and you direct a record to a 
point beyond the last record in the file, any gap is filled with void 
records. 


¢ Ifyou are outputting records randomly and you direct a record to a 
point within the file limits, an error condition results if a valid (not 
deleted) record is at that point. 


RCB=NO 
Indicates that no record contains an RCB. 
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Offset Physical Sector (OFFSET) 


Specify the OFFSET parameter when you want to process (convert) a data set label 
diskette created by an IBM (System/32 or System/34) utility. The first sector of such a 
diskette always contains file control information while the first sector of an OS/3 data 
set label diskette is always used for file data. OFFSET tells consolidated data 
management to position an IBM diskette to the second physical sector so that file 
processing can begin at the first logical record. For more information about converting 
IBM diskettes see the System 32, 34 to OS/3 Conversion Guide (UP-9318). 


OFFSET=1 
Specifies the first sector of a data set label diskette does not contain file 
data. 


General Rewind Options (REWIND) 


This keyword parameter specifies general tape rewinding options. If specified, OPRW 
(see C.2.15) and CLRW (see C.2.16) are ignored. 


REWIND=UNLOAD 
Specifies rewinding of the tape to the load point when the file is opened, and 
specifies unloading of the tape when the file is closed. 


REWIND=NORWD 
Specifies no tape rewinding when the file is opened, and tape positioning to 
the end of volume (between the two tape marks) when the file is closed. Note 


that open processing is identical to OPRW=NORWD, but close processing is 
not identical to CLRW=NORWD. 


Rewinding at File Open (OPRW) 


This keyword parameter specifies a rewinding option for file open. 
OPRW=NORWD 


Specifies no tape rewinding (to load point) before labels are checked during 
file open. 


Rewinding at File Close (CLRW) 


This keyword parameter specifies rewinding options for file close. 


CLRW=NORWD 
Specifies no tape rewinding after the file is closed. 
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CLRW=RWD 
Specifies tape rewinding (to load point), but no unloading after the file is 
closed. 


C.2.17. File Label Type (FILABL) 


This keyword parameter specifies the label type (if any) for the file and is applicable 
to all volumes of a multivolume file. 


FILABL=NO 
Specifies that the file is unlabeled. This specification is not valid for ASCII 
files. 


FILABL=STD 
Specifies that the file has standard labels that conform to system 
conventions. 


FILABL=NSTD 
Specifies that the file has nonstandard labels. This specification is not valid 
for ASCII files. 


C.2.18. Tape Marks (TPMARK) 


This keyword parameter specifies a tape-marking option. 


TPMARK=NO 
Specifies that data management is not to write a tape mark preceding data 
on nonstandard labeled or unlabeled output files. Distinguishing between 
labels and data when reading nonstandard labeled files is your 
responsibility. 


C.2.19. Restoring Initialized Files (RESTORE) 


This keyword parameter enables you to restore a MIRAM disk file after it was 
unintentionally initialized. 


RESTORE=YES 
Beginning with OS/3 Release 12.0, data management will save the record 
count whenever a file is initialized. 


RESTORE=YES allows you to restore a file to its original capacity. The 
number of records written to the file after initialization has overlaid the 
same number of original records. The original records that were overlaid are 
lost; however, the remainder of the original records are present and are 
accessible. It is recommended that you use RESTORE=YES if a file was 
unintentionally initialized and then copy that file to another file. 
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This specification will not work with a file that has been scratched and then 
reallocated into the same physical space it originally occupied or with a file 
that was unintentionally initialized in a release prior to OS/3 Release 12.0. 


RESTORE=n 
Specifies the number of records that data management is to read in order to 
restore the file. Use this specification to read the data partition of the file 
(PCA1) and copy or rebuild the file. The reasons for using this specification 
are 


e Ifthere is a need to restore a portion of the original file, n would 
represent the number of records to restore 


e Ifthe file was scratched and reallocated into the same physical space it 
originally occupied 


° Ifthe file was unintentionally initialized on a release prior to OS/3 
Release 12.0 


You must use a copy program, such as DATA or MILOAD, to copy the file or rebuild 
the index. 


Disk Cache Support (CACHE) 


This keyword parameter and the CACHE IOGEN parameter provide selective caching 
of MIRAM disk files. You may not wish to cache data from a file when: 


e A file is accessed randomly. Caching may not improve performance, but may 
impact it. 


¢ Performance is not a priority in file processing and you wish to reserve the cache 
buffer for other processing. 


Use the CACHE IOGEN parameter to specify the files that are to be cached for the 
disk device. 


e CACHE=YES - cache data from all files. YES is the default. 
¢ CACHE=NO - do not cache data from any files. 
°¢ CACHE=NOMI - cache data from all but MIRAM data files. 


For further information on the CACHE IOGEN parameter, refer to the Installation 
Guide (UP-8839). 


Note that the REMOVE command can also be used to remove a device from the disk 
cache facility. For further information on the disk cache facility and descriptions of all 
cache commands, refer to the Operations Guide (UP-8859). 
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To override a YES or NOMI specification on a file basis, use the CACHE parameter in 
the DD JCL statement. 


CACHE=NO 


Specifies that the file be processed with no caching. Use DD CACHE=NO 


when the device is being cached (IOGEN CACHE=YES) and you do not want 
caching for this file. 


CACHE=YES 
Specifies that the file be processed with caching. Use DD CACHE=YES when 
you specify IOGEN CACHE=NOMI and you want caching for this file. This 
specification is unnecessary if you indicate IOGEN CACHE=YES. If you 
indicate IOGEN CACHEE=NO, this specification is ignored. DD CACHE=YES 
applies only to MIRAM data files. 


C.2.21. Suppressing Error Messages (MSGSUPP) 


This keyword parameter allows you to suppress the display of the DM36 error 
message, the LB05 error message, or all error messages. 


MSGSUPP=DM36 


Specifies that the DM36 DUPLICATE RECORD error message is not to be 
displayed on the console or log. 


MSGSUPP=LB@5 


Specifies that the LB05 MODULE NOT FOUND error message is not to be 
displayed on the console or log. 


MSGSUPP=ALL 


Specifies that all data management error messages are not to be displayed 
on the console or log. 
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Appendix D 


Shared Code and Accelerated File Access 


For each file type (disk, tape, card, and so on), there is a data management processing 
module invoked whenever a file of that type is accessed. These processing modules are 
shared, meaning that when a system or user program requests access of a particular 
file type, a copy of the corresponding module is loaded into main storage for use by any 
program requesting access of the same file type. 


To improve the performance of consolidated data management when accessing files, 
you can make the processing modules for card, printer, tape, diskette, and disk files 
resident. A shared code module designated as resident is loaded when the operating 
system (actually, the supervisor) is loaded and is never moved or deleted. 
Consolidated data management recognizes that the module is resident and takes 
advantage of the fact that the module’s location cannot change. Accelerated file access 
results because control can be transferred to a resident module faster than it can be to 
a nonresident module. 


To designate a module as resident, you must specify the name of the module in the 
é RESHARE parameter during generation of your supervisor (SUPGEN). The file types 

and corresponding module names you can specify are 

File Type Module Name 

Disk D3SM1110 

Diskette D3SM1110 

Tape DDST1110 

Card CDSIOJOO 

Printer PRSIOEOO 


Notes: 


1. Accelerated access is provided only for disk files with share requirements of EXC or 
SRDO. Files with share requirements of SRD, EXCR, or SADD, for example, are 
not provided with accelerated file access even if the disk module is resident. (See 
5.4 for information about disk file share requirements.) 
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2. Acceleration is not provided for single-mount multivolume disk or diskette files or 
multivolume tape files. 


It isn’t necessary to make all the modules resident; only those corresponding to the 


particular file type that you want accelerated access for. For more information about 
the RESHARE parameter, see the Installation Guide (UP-8839). 
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Appendix E 
Data Management Debugging Facility 


E.1. General Information 


The data management debugging facility obtains documentation (a system dump) 
when an unexpected data management error occurs. 


E.2. Console Command 


The following console command will activate the debugging facility: 
SE DE,DM,eess 
where: 


ee 
Is the data management error code. 


$s 
Is the subcode received on the error message. 


You must enter a 4-character code even if there is no subcode associated with the error 
code. For example, to activate the debug facility for a DM06 error, you enter 


SE DE, DM, 0600 


For those error codes that have subcodes, you can enter 00 for the subcode if you want 
a system dump produced for any occurrence of the error code (independent of the 
subcode). 


When the error condition is encountered, an automatic system dump is generated 
(with an error code of 3DE), and the job continues to execute. It does not require a 
debug supervisor, and it will not result in an HPR or abnormal job termination. It is 
automatically deactivated upon the first occurrence of the error condition. 
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